mysql版本不能小于4.1_《MySQL排错指南》——4.1　物理硬件限制-阿里云开发者社区...

本节书摘来自异步社区出版社《MySQL排错指南》一书中的第4章，第4.1节，作者：【美】Sveta Smirnova(斯维特 斯米尔诺娃)，更多章节内容可以访问云栖社区“异步社区”公众号查看。

4.1　物理硬件限制

对性能有不切实际的期望是通常会犯的错。我们要求MySQL服务器在忽略硬件组件延迟的情况下进行优化。因此，理解什么导致了延迟很重要。

下面列出了影响MySQL服务器的硬件资源：

内存

CPU

内核数量

磁盘I/O

网络带宽

我们依次讨论每个细节。

4.1.1　内存

内存对于MySQL是非常宝贵的资源。服务器在没有磁盘交换的情况下运行很快。理想情况是数据驻留在内存中。因此，在物理内存的限制内合理配置缓冲区是非常重要的。关于这一点，1.6.4小节和3.9.3小节提供了更多详细的介绍和指导。

提示　提示

在Linux/UNIX上可以通过vmstat，或者Windows上的任务管理器来查看mysqld是否有大量磁盘交换。

这里列出Linux上一个磁盘交换的例子。重要的部分加粗显示。对于没有磁盘交换的服务器，这些值应该为0：

相关章节讨论了影响内存使用的配置变量。首先计算出MySQL服务器需要用到的最大内存量，基本原则是要保证它小于你的物理内存。当缓冲区大于实际内存时会增加MySQL服务器因为“内存不足”错误而崩溃的风险。

前面的观点可以换一种陈述方式：如果你需要更大的缓冲区，则需要购买更多内存。扩展应用程序时这始终是一个很好的做法。

使用的内存模块支持扩展错误校正(EEC)，这样即使内存有一些损坏，MySQL服务器也不会因此崩溃。

关于内存使用的更多内容，可以参考MySQL参考手册中的“MySQL如何使用内存”章节。我就不在此处重复，因为它不涉及任何新排错技巧。

很重要的一点是，当查询的行包含BLOB字段时，内部缓冲区会增长到能存储该值的点，并且存储引擎在查询结束后不会释放内存。需要执行FLUSH TABLE来释放内存。

另一个要点涉及32位和64位架构的不同。虽然32位使用较小的指针大小可以节约内存，但由于操作系统的寻址受限，它在缓冲区大小设置上存在固有的约束。理论上，每个进程在32位系统上的最大可用内存为4GB，实际上在很多系统上这个数值很小。所以如果你想使用的缓冲区在32位系统上超过了这个值，考虑转换到64位架构下。

4.1.2　处理器与内核

MySQL的性能不会随着CPU的速度线性增长。这并不意味着你不能使用一块快的CPU，但不要期望提高CPU速度能像增加内存那样性能会有大幅提升。

然而，当设置一些影响内部线程并发的选项时，内核的数量很重要。如果你没有足够的内核数增加这些值是没有任何意义的。通过使用一款名叫sysbench[1]的基准工具能够轻松说明问题。表4-1显示了在四核机器上的一个测试结果。我使用具有16个线程的OLTP sysbench测试。

表4-1　不同innodb_thread_concurrency值下执行事件消耗的时间(s)

如你所见，在启动8个线程之前测试越运行越快，但随着数值的增加停止了增长。

4.1.3　磁盘I/O

快速磁盘对MySQL性能很重要。磁盘越快，I/O性能越好。

关于磁盘，你需要关注磁盘读延迟(每次读访问需要多长时间)和fsync延迟(每个fsync耗时多少)。

近来固态硬盘(SSD)的性能很好，但不要指望在上面出现奇迹，因为大多数存储引擎是针对硬盘读写优化的。

同样网络存储也是。可以将数据和日志文件放在网络文件系统或者存储上，但这些装置可能会慢于本地磁盘。你需要检查存储是否快速并且可靠，否则，如果由于网络故障引起数据丢失请不要感到意外。

在Linux/UNIX上使用iostat来判断磁盘I/O是否过载。向设备发起的请求平均队列长度正常情况下不会很高。出于同样的目的，你可以在Windows平台上使用perfmon。下面给出iostat的一个输出例子：

以上输出取自mysqld空闲并随后启动一个活跃的I/O作业时。你可以看到avgqu-sz是如何增长的。虽然还不至于带来问题，但我决定在这里通过这个例子来说明当mysqld正在处理它的作业时磁盘I/O活动是如何发生变化的。

除了速度之外，要牢记的是，存储也可能会丢失数据，可能出现只写入一部分页的情况。如果使用InnoDB，为了数据安全通过设置innodb_double_write使用双写缓冲区。同样，为磁盘准备备用电池是很重要的，它可能防止因为电源故障导致的数据丢失。

4.1.4　网络带宽

客户端几乎总是通过网络连接MySQL到服务器的，所以MySQL服务器运行在一个快速的网络环境下是很重要的。

除了网络带宽之外，往返时间(RTT)和往返次数也很重要。RTT指的是客户端发送网络包到服务端返回应答所消耗的时间。主机间隔的距离越长，RTT越高。

也正是因为存在网络带宽和RTT这些原因，如果可以，推荐将客户端和服务器放在同一个本地网络中。

复制也推荐在本地网络中进行。连接到从服务器时可以使用因特网来替代本地内联网，但预期会出现延迟，甚至中继日志数据损坏带来的报错。上面的错误应该在bug #26489 bug修复之后会自动修复，前提是你在5.5版本中配置了relay-log-recovery选项，或者从5.6版本开始使用二进制日志校验和。但由于网络故障主从服务器之间仍然会在重发包上消耗时间。

4.1.5　延迟效应的例子

为了结束本章内容，我用一个小例子来说明硬件延迟是如何影响一条普通的UPDATE查询的。我们使用InnoDB表并将自动提交打开，同时打开二进制日志文件。

这个简单的查询会在下面的情况下遭遇延迟：

客户端发送命令到服务端历经半个RTT。

执行UPDATE的WHERE子句，mysqld读磁盘。

由于自动提交开启mysqld会对此事务做一个fsync调用。

为写入二进制日志文件Mysqld做一次fsync调用。

为提交改变mysqld做一次fsync调用。

客户端收到来自服务器的结果，这是RTT的另一半。