《高性能MySQL》阅读笔记第八、九章服务器、操作系统、硬件优化

MySQL服务器配置的学习应该是从MySQL内核和行为开始，然后利用这些知识来指导配置MySQL。如果配置不单单考察硬件，配置情况应该更加符合服务器的工作负载、数据和应用需求。配置项只需要修改基本项即可，不应该随便修改，否则会引起很多意料外的问题。多数情况下默认的配置项即可。

一般不建议通过寻找有问题的地方来修改配置项，最好还是从查询语句和相应时间入手开始分析。

本篇从原书第八、九章展开，省略了很多的内容和章节，只选取了自己感觉日常可能会涉及的部分做了简要的记录。

MySQL配置原理

配置信息可以从命令行参数设置或者是在配置文件中设置。

做动态设置务必小心，在线更改设置可能会导致数据库做大量的工作，例如从缓存中刷新脏块。实际操作中都需要详细了解设置更改的立即后果，了解后果再行动。

硬件上及时性能翻倍，例如内存大小翻倍了，但是配置的设置不是简单的乘2这么简单，有可能导致超过地址空间等问题。除非是硬件、工作负载和数据是完全静态的，否则都可能需要重新检查配置文件。

一个完美的配置可能需要不断的通过基准测试迭代验证来获得，需要大量的工作和研究，大部分情况下收益很小，不如把时间花费在检查备份、监控执行计划上。

这些配置影响着MySQL怎样同步数据到磁盘以及如何做恢复操作，I/O操作是代价很大的，如果可以冒一点点风险让数据没有立即持久化到磁盘是，就可以增加并发性和减少I/O等待，配置MySQL I/O也就是多大的持久化风险和高并发性的平衡。

“把日志缓冲写到日志文件”和“把日志刷新到持久化存储”这两者是不同的，写进日志文件只是简单的把数据从InnoDB的内存缓冲转移到操作系统的缓存，并没有把数据写到持久化存储。把日志刷新到持久话存储意味着InnoDB请求操作系统把数据刷出缓存，并且确认写到了磁盘。

上述日志缓冲刷新到持久化存储中，以求提交的事务全部被持久这一过程，在持久化的实效和性能之间如果有权衡的的话可以通过设置innodb_flush_log_at_trx_commit变量来控制日志缓冲刷新的频繁程度。

InnoDB把数据保存在表空间内，本质上是有一个或者多个磁盘文件组成的虚拟文件系统。InnoDB用表空间实现很多功能，不只是存储表和索引，还保存回滚日志、插入缓存、双写缓冲。

在高并发的场景下，因为并发导致的性能降低，唯一的解决办法是限制并发，升级服务器。InnoDB有自己的“线程调度器”控制线程怎么进入内核访问数据、以及他们在内核中一次可以做什么，这其中限制多少线程进入内核是可配置的。同时还可以设置提交阶段的并发数。

MyISAM不像InnoDB样支持MVCC，虽然也是表级锁，但只有插入操作是在表的末尾才能支持并发插入。MyISAM可以设置一个并发插入变量限制并发程度。

InnoDB的默认配置是为硬盘驱动器定制的，在固态硬盘上使用旧版MySQL时需要作这类改进：增加I/O容量、设置更大的InnoDB文件、把而至今日志文件转移到RAID卷节省更多的闪存设备性能、禁用预读、禁用双写缓存、限制插入缓存大小等。

MySQL需要的四种资源是：CPU、内存、硬盘、网络资源，网络一般不会作为很严重的瓶颈出现。对CPU而言，一般会选择更快而不是更多。CPU、内存、磁盘三者在性能上的关系错综复杂，某个部分不足的话可能会在其他地方显现出来问题，具体在某些场景下也应该详细分析例如工作集大小等来决定具体的配置方案。

BaronSchwartz, PeterZaitsev, VadimTkachenko, et al. 高性能MySQL[M]. 电子工业出版社, 2013.