mysql常见的经典问题

MySQL中有哪些存储引擎？

InnoDB存储引擎

InnoDB是MySQL的默认事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期(short-lived)事务，应该优先考虑InnoDB引擎。

MylSAM存储引擎

在MySQL 5.1及之前的版本，MyISAM是默认的存储引擎。MyISAM提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等，但MyISAM不支持事务和行级锁，而且崩溃后无法安全恢复。MyISAM对整张表加锁，很容易因为表锁的问题导致典型的的性能问题。

Mrg_MylSAM

Merge存储引擎，是一组MyIsam的组合，也就是说，他将MyIsam引擎的多个表聚合起来，但是他的内部没有数据，真正的数据依然是MyIsam引擎的表中，但是可以直接进行查询、删除更新等操作。

Archive引擎

Archive存储引擎只支持INSERT和SELECT操作，会缓存所有的写并利用zlib对插入的行进行压缩，所以比MyISAM表的磁盘I/O更少。但是每次SELECT查询都需要执行全表扫描。所以Archive表适合日志和数据采集类应用，Archive引擎是一个针对高速插入和压缩做了优化的简单引擎。

Blackhole引擎

Blackhole引擎没有实现任何的存储机制，它会丢弃所有插入的数据，不做任何保存。可以在一些特殊的复制架构和日志审核时发挥作用。但这种引擎在应用方式上有很多问题，因此并不推荐。

CSV引擎

CSV引擎可以将普通的CSV文件(逗号分割值的文件）作为MySQL
的表来处理，但这种表不支持索引。因此CSV引擎可以作为一种数据交换的机制，非常有用。

Federated引擎

Federated引擎是访问其他MySQL服务器的一个代理，它会创建一个到远程MySQL服务器的客户端连接，并将查询传输到远程服务器执行，然后提取或者发送需要的数据。默认是禁用的。

Memory 引擎

Memory表至少比MyISAM 表要快一个数量级，数据文件是存储在内存中。Memory表的结构在重启以后还会保留，但数据会丢失。

Memroy表在很多场景可以发挥好的作用:

用于查找(lookup）或者映射(mapping）表，例如将邮编和州名映射的表。

用于缓存周期性聚合数据(periodically
aggregated data)的结果。

用于保存数据分析中产生的中间数据。

Memory表支持 Hash索引，因此查找操作非常快。Memroy表是表级锁，因此并发写入的性能较低，每行的长度是固定的，可能导致部分内存的浪费。

NDB集群引擎

使用MySQL服务器、NDB集群存储引擎，以及分布式的、share-nothing 的、容灾的、高可用的NDB数据库的组合，被称为MySQL集群（(MySQL
Cluster)。

 MyISAM和InnoDB的区别是什么?

MyISAM引擎是5.1版本之前的默认引擎，支持全文检索、压缩、空间函数等，但是不支持事务和行级锁，所以一般用于有大量查询少量插入的场景来使用，而且MyISAM不支持外键，并且索引和数据是分开存储的。

InnoDB是基于聚簇索引建立的，和MyISAM相反它支持事务、外键，并且通过MVCC来支持高并发，索引和数据存储在一起。

 请概述下数据库的范式设计

目前关系数据库有六种范式，常见范式：第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。。

范式化设计优缺点:

优点:可以尽量得减少数据冗余，使得更新快，体积小；缺点:对于查询需要多个表进行关联，减少写得效率增加读得效率，更难进行索引优化

反范式化:

优点:可以减少表得关联，可以更好得进行索引优化；缺点:数据冗余以及数据异常，数据得修改需要更多的成本，常见的反范式设计有缓存、冗余等等。

 数据库表设计时，字段你会如何选择？

更小的通常更好，应该尽量使用可以正确存储数据的最小数据类型。更小的数据类型通常更快，因为它们占用更少的磁盘、内存和CPU缓存，并且处理时需要的CPU周期也更少。但是要确保没有低估需要存储的值的范围。

简单就好，简单数据类型的操作通常需要更少的CPU周期。例如，整型比字符操作代价更低，比如应该使用MySQL内建的类型而不是字符串来存储日期和时间。

尽量避免NULL，如果查询中包含可为NULL的列，对MySQL来说更难优化，因为可为NULL的列使得索引、索引统计和值比较都更复杂。可为NULL的列会使用更多的存储空间，在MySQL里也需要特殊处理。当可为NULL的列被索引时，每个索引记录需要一个额外的字节。

 mysql里记录货币用什么字段类型好？

MySQL既支持精确类型的存储DECIMAL类型，也支持不精确类型存储FLOAT和 DOUBLE类型。对于货币记录，应该选择DECIMAL类型，但是DECIMAL类型是以字符串形式存放的，所以性能会有影响。

作为替代方案，可以在数据量比较大的而且要求精度时，虑使用BIGINT代替DECIMAL，将需要存储的货币单位根据小数的位数乘以相应的倍数即可。

 谈谈MySQL里的字符串类型

MySQL里的字符串类型有：SET、BLOB、ENUM、VARCHAR、CHAR、TEXT。VARCHAR和 CHAR是两种最主要的字符串类型。VARCHAR类型用于存储可变长字符串，大部分的业务情况下比定长类型更节省空间，CHAR类型是定长的，CHAR适合存储很短的字符串，或者所有值定长或都接近同一个长度。

使用BLOB和TEXT则要慎重，一般把 BLOB或TEXT 列分离到单独的表中，还可以对BLOB或TEXT 列使用合成的(Synthetic)索引，就是根据大文本字段的内容建立一个散列值并单独存储在数据列中，可以通过检索散列值找到数据行。如果表中的字段的取值是固定几个字符串，可以使用枚举列代替常用的字符串类型。

 VARCHAR(M)最多能存储多少数据？

对于VARCHAR(M)类型的列最多可以定义65535个字节。其中的M代表该类型最多存储的字符数量，但在实际存储时并不能放这么多。

MySQL对一条记录占用的最大存储空间是有限制的，除了BLOB或者TEXT类型的列之外，其他所有的列（不包括隐藏列和记录头信息）占用的字节长度加起来不能超过65535个字节。所以MySQL服务器建议我们把存储类型改为TEXT或者BLOB的类型。这个65535个字节除了列本身的数据之外，还包括一些其他的数据，从行记录格式我们可以得知，为了存储一个VARCHAR(M)类型的列，其实需要占用3部分存储空间：真实数据、真实数据占用字节的长度、NULL值标识，如果该列有NOT
NULL属性则可以没有这部分存储空间。

我们假设表中只有一个VARCHAR字段的情况：

如果该VARCHAR类型的列**没有**NOT NULL属性，那最多只能存储65532个字节的数据，因为真实数据的长度可能占用2个字节，NULL值标识需要占用1个字节。

如果VARCHAR类型的列**有**NOT NULL属性，那最多只能存储65533个字节的数据，因为真实数据的长度可能占用2个字节，不需要NULL值标识。

如果VARCHAR(M)类型的列使用的不是ascii字符集，那M的最大取值取决于该字符集表示一个字符最多需要的字节数。在列的值允许为NULL的情况下，gbk字符集表示一个字符最多需要2个字节，那在该字符集下，M的最大取值就是32766（也就是：65532/2），也就是说最多能存储32766个字符；utf8字符集表示一个字符最多需要3个字节，那在该字符集下，M的最大取值就是21844，就是说最多能存储21844（也就是：65532/3）个字符。

不管如何，请牢记：**MySQL****一个行中的所有列（不包括隐藏列和记录头信息）占用的字节长度加起来不能超过65535****个字节**。

 什么是虚拟生成列？

虚拟生成列又叫GeneratedColumn，是MySQL 5.7引入的新特性，就是数据库中这一列由其他列计算而得。在MySQL 5.7中，支持两种Generated
Column，即Virtual
Generated Column（虚拟生成的列）和Stored
Generated Column（存储生成的列），二者含义如下：

1、Virtual
Generated Column（虚拟生成的列）：不存储该列值，即MySQL只是将这一列的元信息保存在数据字典中，并不会将这一列数据持久化到磁盘上，而是当读取该行时，触发触发器对该列进行计算显示。

2、Stored
Generated Column（存储生成的列）： 存储该列值，即该列值在插入或更新行时进行计算和存储。所以相对于Virtual Column列需要更多的磁盘空间，与Virtual
Column相比并没有优势。因此，MySQL
5.7中，不指定Generated
Column的类型，默认是Virtual
Column

在表中允许Virtual
Column和Stored
Column的混合使用

提高效率：由于mysql在普通索引上加函数会造成索引失效，造成查询性能下降，Generated Column（函数索引）刚好可以解决这个问题，可以在Generated