在SSD上基准MySQL：工具和策略

Question

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

我有 3,800,000行（16GB）表作为基准表。

我的服务器设置：

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

我有两件事我会非常考验：

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

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

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

Answer 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上测试了一些东西，发现查询性能比我的7200rpm SATA磁盘快10倍左右。在基于SSD的事务数据库中，使用OPTIMIZE TABLE时要小心，因为频繁的数据库压缩与SSD TRIM结合可能会影响磁盘寿命。这是理论上的，我还没有看到证据支持这一点。

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

Answer 2

通用测试没问题，但只有实际负载会告诉你软件和软件之间的区别。硬件配置。也许试着：

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

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

Answer 3

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

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