June 15, 2013

[MySQL 5.6] 初识5.6的optimizer trace

在MySQL5.6中,支持将执行的SQL的查询计划树记录下来,目前来看,即使对于非常简单的查询,也会打印出冗长的查询计划,看起来似乎不是很可读,不过对于一个经验丰富,对查询计划的生成过程比较了解的DBA而言,这是一个优化SQL的宝藏,因为暴露了大量的内部产生查询计划的信息给用户,这意味着,我们可以对开销较大的部分进行优化。 新参数optimizer_trace可以控制是否为执行的SQL生成查询计划树,默认关闭,我们也建议关闭,因为它会产生额外的性能开销(dimitrik的评测:http://dimitrik.free.fr/blog/archives/2012/01/mysql-performance-overhead-of-optimizer-tracing-in-mysql-56.html)。 我在自己的机器上使用sysbench测试,64个并发,select.lua,纯内存操作,QPS从112,000下降到88,000。 这是session级别的参数,如果需要是,可以在session级别打开,线程只能看到当前会话的查询计划,无法看到其他会话的。 使用也很简单: 打开optimizer_trace mysql> set session optimizer_trace=’enabled=on’; Query OK, 0 rows affected (0.00 sec) <执行你的SQL>  (例如,这里执行select * from sbtest1 order by k limit 3;) 然后查询information_schema.optimizer_trace表,输出如下 | select * from sbtest1 order by k limit 3 | {   “steps”: [     {       “join_preparation”: {         “select#”: 1,         “steps”: [           […]