MySql InnoDB 高级应用

通常我们在项目中，MySql遇到瓶颈有几大因素。

1. 记录条数。

2. 数据特性。

3. 操作时机。

4. 热点数据。

5. 配置。

6. 硬件。

下面针对这6大因素说一下常见的优化、配置。

1. 记录条数

当表大小小于InnoDB_buffer_pool时，增提性能会随着表记录增加而略微降低性能。但不会降低很多，总体性能差别不大。

当表大小大于InnoDB_buffer_pool时，性能会急剧下降。此时磁盘IO成为了性能下降的主要因素。

因此得到结论，表记录数本身对应能影响不大。关键在于表的大小是否小于Innodb_buffer_pool。

2. 数据特性

理论上说NT比CHAR更快。原因是iNT运算更快，长度更短。

但通过实际测试得出，INT比CHAR更快的原因还是因为更短，减少了磁盘空间与磁盘IO。从而性能高。 (长度才是关键)

理论上说char比varchar速度快。

但在实际项目中在字段长度在120-220 之间，把char、varchar都设置220长度时，varchar的性能高于char。 原因是varchar能节省磁盘空间，内容更短，所以性能更高。 (可以得到结论，当需要存储指定长度的内容时使用char是最佳选择，而当内容长度不一致时，varchar才是最佳选择。)

key的长度越长，表就越大。当表大于Innodb_buffer_pool时，性能下降明显。 主键对表大小影响很明显，因为InnoDB把主键当做行标识。没个索引都会存放主键，主键越大，索引越大。

3. 操作时机

初始值： MySQLInnoDB需要将数据从磁盘载入内存

稳定值：数据已经完成从磁盘载入到内存的操作

初始值主要是磁盘操作，表大小和磁盘IO速度成为了影响性能的关键因素

稳定值主要是内存操作，内存大小成为影响性能的关键。

如果一个业务刚上线时，为了让性能更好，可以 select * 或select count(*) 把数据写入到内存，这样当业务来后，性能会好。

4. 热点数据

热点数据性能：InnoDB buffer poll的大小大于热点数据大小时，热点数据性能比随机访问高很多，内存小于热点数据时，性能比随机访问高一点。 原因是InnoDB buffer poll采用LRU淘汰算法管理内存

5. 配置

sync_binlog ： 执行多少条操作后写入binlog日志。  通常设置为 1，而高性能时设置的值越大性能越高，但也要根据binlog的需求适当来设置。 这里推荐100。

InnoDB_flush_log_at_trx_commit  ： 事务日志刷盘。 值为 1时，当执行事务后立刻写入日志，值为 2时，当积攒到一定量时再刷盘。 通常设置为1，而高性能时设置为 2.

在查询操作时，上面两项配置对性能是没有任何影响的，因为查询操作并不写日志。

当表大小大于InnoDB_buffer_pool时，上面两种配置区别也并不大，因为InnoDB_buffer_pool不能把这个表都放到内存中。

当innodb日志文件和数据文件在同一磁盘时，性能下降会很明显。 原因相信大家也都能猜到是“IO瓶颈”。

当innodb日志文件配置的太小时，性能下降也会非常明显，原因是频繁的checkpoint。 推荐把日志文件设置成200M，配置3个。

6. 硬件

磁盘性能

当磁盘ID达到瓶颈时，应选择更合适的存储设备(废话)。如果采用的是RAID卡，那么尝试开启回写功能。 (目前最好的方法是换SSD， 毕竟SSD价格也降下来了)

系统内存不够时性能下降明显

至少要给系统留4G的内存空间。 当内存不够时，加加加！