所以我对慢速查询日志的理解是，它记录了我们在my.conf文件中设置的＆gt; = time（以秒为单位）的所有查询的信息。
现在让我们看看3种不同的SELECT查询（针对具有INNODB引擎的表）：
QUERY I： Query_time：32.937667 Lock_time：0.000081 Rows_sent：343 Rows_examined： 12714043
QUERY II： Query_time：12.937667 Lock_time：0.000081 Rows_sent：43 Rows_examined： 714043
QUERY III： Query_time：42.937667 Lock_time：0.000081 Rows_sent：18 Rows_examined： 483
对我而言，QUERY I和QUERY II看起来都是可能出现错误查询或索引不当（或缺少索引）或碎片化表格数据等问题（我可能错过的任何其他内容？）用户可能会看到改进查询执行时间。
但是对于QUERY III，我无法理解我的意思，我的意思是数据库可能真的出错了需要花费42秒来检查483行并发回18行（带有可忽略的锁定时间）。当我看到它间歇性地发生时，这变得更加混乱。
所以我真正想问的是：
可能会有很多因素影响这种慢查询，所以万一你觉得自己需要更多信息来帮助我，请告诉我。
答案 0 :(得分：26)
锁定时间是在查询开始执行之前花费的时间。即，等待其他线程放弃对当前查询需要锁定的数据的锁定的时间。
查询时间是执行查询的时间。如果行尚未存在于缓冲池中，则可能涉及等待I / O.在将数据加载到缓冲池之后，对相同数据重复相同的查询可能会更快。
如果您的查询在磁盘上为给定查询排序，即使它检查的行数也很慢。
如果您的I / O系统负担过重，您可能会出现间歇性缓慢。这也可能发生在虚拟化I / O上（例如，廉价的AWS实例）。或者，如果您的磁盘开始出现故障，它们可能会间歇性地出错。
监控 iostat 并观察队列长度，平均等待时间和服务时间。查看是否存在缓慢的时期，或者性能和吞吐量是否一致。
检查行并不反映获取给定行所需的多个I / O.例如，如果该行在溢出页面上存储了大量大BLOB / TEXT / VARCHAR列。或者，如果事务需要访问回滚段以获取某些行的旧版本，如果它们在此事务开始后已被修改。
检查的行也没有告诉我们查询中的表达式有多复杂。你可能正在计算Fibonacci sequences in stored functions或类似的东西。
在没有查看查询及其EXPLAIN报告的情况下，如果只考虑慢查询日志中的那些数字，就很难对其进行解释。
MySQL当然可以在一个表中存储2亿行，但是在这种规模下，即使索引可以将搜索减少到483行，也会开始出现性能问题。这是因为depth of the B-tree index and size of an indexed column与查找这483行所需的I / O操作数直接相关。 I / O越多，所需的时间就越长，并且这不会被检查的行反映出来。查询时间包括I / O时间，但不清楚I / O有多少查询时间。
其他一些寻找更详细诊断的地方是：
MySQL Query Profiler（但请注意，这已被弃用，以支持性能架构）
Enhanced verbosity slow query log in Percona Server报告查询等待I / O的时间。
答案 1 :(得分：1)
Query_time：12.937667 Lock_time：0.000081 Rows_sent：43 Rows_examined：714043
Query Time: Total time including lock time query has taken
Lock_Time: Total query query was in a locked state
Rows sent: Total rows sent by server to client
Rows examined: Total rows scanned by a MySQL server for a query