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

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

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

我的服务器设置：

• Ubuntu 64 + Nginx + MySQL 5.5 + ...

我心里有两件事我想进行大量测试：

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

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

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

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

mysql> reset query cache;

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

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

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

希望这可以帮助！我迫不及待地希望磁性 HD 取代磁带作为备份介质，并发现自己在大多数硬件中完全被 SSD 取代。