Chapter 7 操作系统和硬件优化
MySQL 服务器中最弱的部分决定了其性能，它的操作系统和硬件通常也会成为限制因素。磁盘大小、可用内存、CPU 资源、网络和连接它们的组件一起决定了系统的最终容量。
前面的章节主要讨论了 MySQL 服务器和应用程序，这种类型的调优是很关键的，但是同时也应该考虑到硬件并且适当地配置系统。例如，如果工作负载是 I/O 密集型的，那么设计应用程序的一个目的就是最小化 MySQL 的 I/O 负载。但是在通常情况下，升级 I/O 子系统，安装更多内存或重新配置已有磁盘是更为明智的选择。
7.1 什么限制了 MySQL 的性能
许多不同的硬件可以影响 MySQL 的性能，但是最常见的两个瓶颈是 CPU 饱和与 I/O 饱和。CPU 饱和发生在 MySQL 使用的数据能被装入内存，或者能够尽快根据需要从磁盘上读取的时候。密集的加密操作及在多个产品之间执行无索引的联接操作都是引发 CPU 饱和的例子。
从另一方面来说，I/O 饱和通常发生在需要的数据比内存多得多的时候。如果应用程序分布在网络上，查询数据相当巨大，或者要求很低的延时，瓶颈就会转移到网络上。
7.2 如何为 MySQL 选择 CPU
在升级当前硬件或购买新硬件的时候，应该考虑工作负载不是 CPU 密集的。
可以通过检查 CPU 使用率来确认负载是否是 CPU 密集的，但要注意不是只检查 CPU 总体负载有多重，而是要查明对于最重要的查询，CPU 使用率和 I/O 之间的平衡，以及注意 CPU 的负载是否均衡。可使用 mpstat、iostat 及 mstat（例子在本章最后）这些工作来查明什么因素限制了服务器的性能。
7.2.1 快 CPU 好还是多 CPU 好？
对于 CPU 密集的负载，MySQL 通常从更快的 CPU 中获益（不是更多 CPU），但事实并不总是如此，因为这依赖于负载和 CPU 的数量。但是，当前 MySQL 的架构对多 CPU 的扩展性不好，并且 MySQL 不能在多个 CPU 上并行地运行某个查询，因此在对于单个 CPU 进行密集的查询时，CPU 速度限制了响应速度。通常来说，想要的性能有两类：
低延迟（快速响应时间）
高吞吐量
如果使用了多个CPU，并且没有并发地运行查询。MySQL 的后台线程可以为一些任务分配额外的 CPU 资源。这些任务包括清理 InnoDB 缓冲区、网络操作等。但是，这些工作比起查询来通常不算什么。如果使用双 CPU 系统来运行一个 CPU 密集的查询，那么某个 CPU 可能在 90% 的时间都是空闲的。
快速的 CPU， 而不是多个 CPU，会让 MySQL复制（下一章）达到最佳工作状态。如果工作负载是 CPU 密集型的，主服务器上的并行负载能轻易地变成从服务器无法跟上单一负载，即使从服务器比主服务器更强大也不能避免这种情况，这说明 I/O 子系统，而不是 CPU，常常会成为从服务器的瓶颈。
如果工作负载是 CPU 密集型的，决定到底是采用快速的 CPU 还是多 CPU 的方式就需要明白查询到底做了什么。在硬件层，查询可能处于执行状态或等待状态。最常见的等待原因有几种：查询在运行队列中（进程可以运行，但是 CPU 繁忙）、等待锁定，以及等待磁盘或网络。在这些情况下，通常需要更快的 CPU。（但是也有例外，例如查询正在等待 InnoDB 日志缓存互斥量，它只有在I/O 完成之后被释放掉，这意味着实际需要更多的 I/O 容量。）
MySQL 在某些负载下能够使用多个 CPU。例如，假设有许多连接正在查询不同的表（因此不会竞争表锁，但对于 MyISAM 表和 Memory 表，这会成为问题），并且服务器的总吞吐量比单个查询响应要重要得多，吞吐量在这种场景下会很高，因为所有的线程可以并发地运行并且彼此不会有竞争。要再次说明的是，这在理论上比实际上工作得更好：不管查询读取的是否是相同的表，InnoDB 都有扩展性问题，并且 MyISAM 在每个键缓冲区上有全局锁。MyISAM 表上的全表扫描是可以并发地运行而不会引发竞争的一个例子。
MySQL 宣称正处于设计中的 Falcon 存储引擎可以使用至少 8 个CPU ， 所以未来的 MySQL 也许能比现在更有效地使用多 CPU。但是只有时间能证明 Falcon 的真实扩展性。
7.2.2 CPU 架构
现在 64 位架构比几年前更加流行。MySQL 在 64 位架构上工作得很好，尽管有某些内部机制不能与 64 位系统兼容。例如，在 MySQL 5.0 中，每个 MyISAM 键缓冲区都被限制在 4GB，这是由 32 位整数寻址的地址空间所决定的（但是可以通过定义多个键缓冲区来绕过这个问题）。
为所有的新硬件选择 64 位架构是一个好主意。如果没有使用 64 位操作系统和 64 位 CPU，就不能有效地使用大量的内存。尽管一些 32 位系统能够支持大量的内存，但是系统不能像 64 位系统那样有效地使用它们，并且 MySQL 也不能很好地使用它们。
- Look beyond the obvious when you think you’ve found a bottleneck. A weakness in one area often puts pressure on another subsystem, which appears to be the problem. For example, if you don’t have enough memory, MySQL might have to flush caches to make room for data it needs – and then, an instant later, read back the data is just flushed(this is true for both read and write operations). The memory scarcity can thus appear to be a lack of I/O capacity. Similarly, a saturated memory bus can appear to be a CPU problem. In fact, when we say that an application has a “CPU bottleneck” or is “CPU-bound”, what we really mean is that there is a computational bottleneck. We delve into this issue next.Back