SSD 上的 MySQL 基准测试：工具和策略答案

【问题标题】：Benchmark MySQL on SSD: Tools and StrategiesSSD 上的 MySQL 基准测试：工具和策略
【发布时间】：2012-07-12 09:35:15
【问题描述】：

我目前正在将我的服务器从在硬盘驱动器上运行 MyISAM 切换到在 SSD 上运行 InnoDB。

我有一个 3,800,000 行 (16GB) 表作为基准表。

我的服务器设置：

Ubuntu 64 + Nginx + MySQL 5.5 + ...

我有两件事要测试：

从硬盘驱动器切换到 SSD 将如何影响并发性
从 MyISAM 切换到 InnoDB 将如何影响并发

我对工具和策略都有疑问：

由于我对并发最感兴趣，我应该使用什么工具来进行测试？我玩过 Siege，发现它真的很容易玩和。但我认为应该有很多更强大的 linux 软件更适合我的需求。
测试策略是什么样的？我了解策略的选择可能与我选择使用的工具密切相关。例如，在玩 Siege 时，我需要编写一个 PHP 脚本来执行一些繁重的 MySQL 操作，将其上传到服务器，将脚本 URL 作为参数传递给 Siege（安装在我的本地笔记本电脑中）并让 Siege为我模拟并发流量。

【问题讨论】：

16GB/380K 行:: 你的平均行大小 > 32K。也许你应该重新设计你的数据模型？
@wildplasser 抱歉，应该是 3,800,000。我刚刚更新了我的问题。感谢您指出这一点！

标签： mysql sql database linux

【解决方案1】：

在 Linux 中对 MySQL 存储性能进行基准测试时要记住的重要一点是缓存。我自己对同样的测试用例很好奇。当用户抱怨查询缓慢时，这总是很有趣。他们打电话给您并再次运行，却发现由于查询缓存，他们的 50 多分钟查询现在在 30 秒内完成。总是运行一个

mysql> reset query cache;

在 MySQL 中尝试优化查询时。也就是说，将 SSD 与传统主轴进行比较时，还有一个步骤：磁盘缓存。当操作系统自己在内存中缓存磁盘时，很难比较访问时间或 IOps。要清除磁盘缓存，请从 shell 运行以下命令：

$ sync && sysctl -w vm.drop_caches=3

这些命令在您的每个基准查询之前运行，将帮助您了解 SSD 与您拥有的 7k2 SATA 慢速存储器相比的潜力。通过运行相同的查询两次而不刷新缓存并观察查询时间来验证这一点。此时，最好尝试一些带有和不带索引的查询，如果可能的话，还可以尝试一些连接。对每个查询使用 EXPLAIN PLAN 来验证是否使用了索引。索引和数据文件之间的随机读取访问将暴露较慢磁盘上的瓶颈。确保你的 my.cnf 在你的 SSD 基准和你的盘片之间是一致的。我在一个简单的桌面 OCZ SSD 上测试了一些东西，发现查询性能提高了大约 10 倍于我的 7200rpm SATA 磁盘。在基于 SSD 的事务数据库中，使用 OPTIMIZE TABLE 时我会小心，因为频繁的数据库压缩与 SSD TRIM 相结合可能会影响磁盘寿命。不过这是理论上的，我还没有看到支持这一点的证据。

希望这会有所帮助！我已经等不及磁性 HD 取代磁带作为备份介质并在大多数硬件中完全被 SSD 取代的日子了。

【讨论】：

【解决方案2】：

通用测试是可以的，但只有实际负载才能告诉您软件和硬件配置之间的区别。也许尝试：

从生产服务器转储数据库
从生产服务器捕获所有查询（使用慢查询日志，设置 long_query_time = 0）
将数据库加载到测试配置中并在其上播放慢查询日志（使用 pt-log-player）。
再次捕获来自测试服务器的所有查询，long_query_time = 0。
使用 pt-query-digest 分析慢查询日志的结果。

我在这里引用了来自Percona Toolkit 的 MySQL 工具（虽然有些工具可能需要 Percona Server，但我不确定）。

【讨论】：

【解决方案3】：

SSD 的类型和质量有很大的不同。如果您的服务器繁忙，请勿将桌面 SATA SSD 用于 mysql。你不会得到你认为你会得到的性能提升。

这里有一些很棒的文章：http://www.mysqlperformanceblog.com/search/innodb+log+file+ssd/

【讨论】：