我正在尝试设置一个脚本,用于测试开发mysql服务器上的查询性能。以下是更多详细信息:
SELECT ... LIKE '%xy%'
)我想做的是创建可靠的测试环境来测量单个查询的速度,摆脱对其他变量的依赖。
到目前为止,我一直在使用SQL_NO_CACHE,但有时这类测试的结果也会显示缓存行为-第一次运行花费更长的时间,而后续运行花费更少的时间。
如果有人可以详细解释这种行为,我可能会坚持使用SQL_NO_CACHE
;我相信这可能是由于文件系统缓存和/或用于执行查询的索引缓存所致,正如this post所解释的那样。我不清楚Buffer Pool和Key Buffer何时失效,也不清楚它们会如何影响测试。
那么,除了重启mysql服务器之外,您建议如何设置一个可靠的环境来确定一个查询是否比另一个执行得更好?
发布于 2010-05-07 00:42:22
假设您不能优化LIKE操作本身,您应该尝试优化基本查询,而不是最小化应该检查的行数。
一些可能对此有用的东西:
解释SELECT中的rows
列...结果。然后,
mysql> set profiling=1;
mysql> select sql_no_cache * from mytable;
...
mysql> show profile;
+--------------------+----------+
| Status | Duration |
+--------------------+----------+
| starting | 0.000063 |
| Opening tables | 0.000009 |
| System lock | 0.000002 |
| Table lock | 0.000005 |
| init | 0.000012 |
| optimizing | 0.000002 |
| statistics | 0.000007 |
| preparing | 0.000005 |
| executing | 0.000001 |
| Sending data | 0.001309 |
| end | 0.000003 |
| query end | 0.000001 |
| freeing items | 0.000016 |
| logging slow query | 0.000001 |
| cleaning up | 0.000001 |
+--------------------+----------+
15 rows in set (0.00 sec)
然后,
mysql> FLUSH STATUS;
mysql> select sql_no_cache * from mytable;
...
mysql> SHOW SESSION STATUS LIKE 'Select%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Select_full_join | 0 |
| Select_full_range_join | 0 |
| Select_range | 0 |
| Select_range_check | 0 |
| Select_scan | 1 |
+------------------------+-------+
5 rows in set (0.00 sec)
另一个有趣的值是last_query_cost
,它显示优化器估计查询的开销(该值是随机页面读取的数量):
mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+-------------+
| Variable_name | Value |
+-----------------+-------------+
| Last_query_cost | 2635.399000 |
+-----------------+-------------+
1 row in set (0.00 sec)
MySQL文档是您的朋友。
发布于 2010-05-08 00:36:23
引用自this page:SQL_NO_CACHE选项会影响查询缓存中查询结果的缓存。如果您的表非常小,则表本身可能已经被缓存。因为您只是避免缓存结果,而不是表,所以有时会得到所描述的行为。因此,正如在其他帖子中所述,您应该在查询之间使用flush your tables。
发布于 2010-05-06 03:59:35
正如链接文章所建议的,在测试运行之间使用FLUSH TABLES
尽可能地重置(特别是查询缓存)。
您的测试是否应该考虑到InnoDB本身在实际性能期间会有不同的状态,这样您就会对多个试验的聚合性能感兴趣?如果你想为每个试验重置InnoDB,你的性能测试会有多“真实”?您拒绝的查询,因为它在重启后立即表现不佳,可能是InnoDB稍微预热后的最佳查询。
如果我是您,我会关注查询优化器在InnoDB的性能之外所做的事情。有很多关于如何调优InnoDB的文章,但从好的查询开始是很有帮助的。
您还可以尝试使用等效的MyISAM表来测量性能,在这种情况下,FLUSH TABLES
实际上会将您重新设置为一个基本相同的起点。
您是否尝试过完全关闭查询缓存?即使使用SQL_NO_CACHE,仅启用查询缓存也会带来大约3%的性能损失。
https://stackoverflow.com/questions/2756100
复制相似问题