您当前的位置: 首页 » MySQL/MSSQL编程 » MySQL微秒慢查询补丁
MySQL微秒慢查询补丁
论坛链接
MySQL微秒慢查询(microtime slow query)补丁包具有以下特色：
[size=4]
[size=5][size=5]识别连接[/size][/size][/size]
每个慢查询结果中都记录了是哪个连接线程引起的，如下：
# Thread_id: 571
[size=4]微秒计数[/size]
可以记录执行时间在1秒一下的慢查询，选项long_query_time的单位现在是微秒，而不是秒，例如设置成300000表示0.3秒。
# Query_time: 0.021752 Lock_time: 0.000016 Rows_sent: 1 Rows_examined: 103
[size=4]记录复制产生的慢查询[/size]
通常情况下，MySQL并不记录复制产生的慢查询，使用该补丁后，只需要打开选项--log-slow-slave-statements解决这一问题。
[size=4]详细的查询执行计划[/size]
每次查询的执行计划都不一样。可能使用索引扫描，或者全表扫描，或者使用临时表。通常这些信息也能从EXPLAIN结果中得到。该补丁会在日志中显示了查询中最重要的几个方面，如下：
1. # QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Tmp_table_on_disk: No
2. # Filesort: Yes Filesort_on_disk: No Merge_passes: 0QC_Hit表示本次查询是否命中了查询缓存(Query Cache)。如果显示的是0，则表示该查询并没有真正的执行。
如果Full_scan的结果为Yes表示该查询比较糟糕，因为需要扫描全表。
Full_join表示联合查询时没有使用索引。
如果需要创建临时表，则Tmp_table的结果为Yes；如果需要创建基于磁盘的临时表而不是基于内存的，则Disk_tmp_table的值为Yes。
如果用到filesort算法，则Filesort的值为 Yes，Filesort_on_disk则表示排序是基于临时文件进行的。
[size=4]InnoDB 的使用[/size]
最后一部分是InnoDB使用结果的统计。MySQL现在允许运行SHOW SESSION STATUS来查看每个线程的统计信息，但是这并不包括InnoDB的使用，因为InnoDB部分而总是显示全局统计的结果。该补丁允许你查看每次查询的InnoDB资源使用情况。
# InnoDB_IO_r_ops: 3 InnoDB_IO_r_bytes: 49152 InnoDB_IO_r_wait: 0.018690
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 7InnoDB_IO_r_ops统计计划需要读取的页数。实际数量可能不太一样，虽然它可以异步完成，不幸的是并没有好办法来衡量它。它的单位是字节(bytes)。
从InnoDB_IO_r_wait中可以看到 InnoDB 从存储引擎中读取数据锁等待的时间(单位是秒)。
InnoDB_rec_lock_wait表示等待行锁所需时间(单位是秒)。
InnoDB_queue_wait表示等待进入 InnoDB 队列或在队列中等待执行所消耗的时间(单位是秒)。
InnoDB_pages_distinct显示了读取的独立页个数。这只是基于用小哈希数组表示的整个缓冲池的近似值，因为有可能需要用很大的内存来映射所有页。同一个查询却产生不准确的读取页数量增长可能是发生了哈希冲撞的缘故。
如果查询中没有用到InnoDB，则相关日志行变成下面这样，其他的不变：
# No InnoDB statistics available for this query注意：尽管该补丁已经做过压力测试，并且还在实际环境中使用过，但仍然建议不要在非常重要的系统中使用，万一出了问题，人家可不负责啊 :)
TAG: mysql MySQL Mysql 查询 微秒 [ 本帖最后由 tznktg 于 2008-11-5 10:25 编辑 ]
[size=4]
[size=5][size=5]识别连接[/size][/size][/size]
每个慢查询结果中都记录了是哪个连接线程引起的，如下：
# Thread_id: 571
[size=4]微秒计数[/size]
可以记录执行时间在1秒一下的慢查询，选项long_query_time的单位现在是微秒，而不是秒，例如设置成300000表示0.3秒。
# Query_time: 0.021752 Lock_time: 0.000016 Rows_sent: 1 Rows_examined: 103
[size=4]记录复制产生的慢查询[/size]
通常情况下，MySQL并不记录复制产生的慢查询，使用该补丁后，只需要打开选项--log-slow-slave-statements解决这一问题。
[size=4]详细的查询执行计划[/size]
每次查询的执行计划都不一样。可能使用索引扫描，或者全表扫描，或者使用临时表。通常这些信息也能从EXPLAIN结果中得到。该补丁会在日志中显示了查询中最重要的几个方面，如下：
1. # QC_Hit: No Full_scan: No Full_join: No Tmp_table: Yes Tmp_table_on_disk: No
2. # Filesort: Yes Filesort_on_disk: No Merge_passes: 0QC_Hit表示本次查询是否命中了查询缓存(Query Cache)。如果显示的是0，则表示该查询并没有真正的执行。
如果Full_scan的结果为Yes表示该查询比较糟糕，因为需要扫描全表。
Full_join表示联合查询时没有使用索引。
如果需要创建临时表，则Tmp_table的结果为Yes；如果需要创建基于磁盘的临时表而不是基于内存的，则Disk_tmp_table的值为Yes。
如果用到filesort算法，则Filesort的值为 Yes，Filesort_on_disk则表示排序是基于临时文件进行的。
[size=4]InnoDB 的使用[/size]
最后一部分是InnoDB使用结果的统计。MySQL现在允许运行SHOW SESSION STATUS来查看每个线程的统计信息，但是这并不包括InnoDB的使用，因为InnoDB部分而总是显示全局统计的结果。该补丁允许你查看每次查询的InnoDB资源使用情况。
# InnoDB_IO_r_ops: 3 InnoDB_IO_r_bytes: 49152 InnoDB_IO_r_wait: 0.018690
# InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000
# InnoDB_pages_distinct: 7InnoDB_IO_r_ops统计计划需要读取的页数。实际数量可能不太一样，虽然它可以异步完成，不幸的是并没有好办法来衡量它。它的单位是字节(bytes)。
从InnoDB_IO_r_wait中可以看到 InnoDB 从存储引擎中读取数据锁等待的时间(单位是秒)。
InnoDB_rec_lock_wait表示等待行锁所需时间(单位是秒)。
InnoDB_queue_wait表示等待进入 InnoDB 队列或在队列中等待执行所消耗的时间(单位是秒)。
InnoDB_pages_distinct显示了读取的独立页个数。这只是基于用小哈希数组表示的整个缓冲池的近似值，因为有可能需要用很大的内存来映射所有页。同一个查询却产生不准确的读取页数量增长可能是发生了哈希冲撞的缘故。
如果查询中没有用到InnoDB，则相关日志行变成下面这样，其他的不变：
# No InnoDB statistics available for this query注意：尽管该补丁已经做过压力测试，并且还在实际环境中使用过，但仍然建议不要在非常重要的系统中使用，万一出了问题，人家可不负责啊 :)
TAG: mysql MySQL Mysql 查询 微秒 [ 本帖最后由 tznktg 于 2008-11-5 10:25 编辑 ]