拿到后Query_ID后，可执行 show profile for query Query_ID ，查看详细的准备时间，执行时间、执行结束（ preparing、executing、end ）等。
显示用户正在运行的线程，需要注意的是，除了 root 用户能看到所有正在运行的线程外，其他用户都只能看到自己正在运行的线程，看不到其它用户正在运行的线程。除非单独个这个用户赋予了PROCESS 权限。
显示字段包含： User| Host| db | Command | Time| State| Info 等。
解析语句，查询是否命中索引，及，命中何种索引，用以判断是否符合我们的预期。
返回字段包含： select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra 等。
select_type 常见类型：
(1) SIMPLE(简单SELECT，不使用UNION或子查询等)
(2) PRIMARY(子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY)
(3) UNION(UNION中的第二个或后面的SELECT语句)
(4) SUBQUERY(子查询中的第一个SELECT，结果不依赖于外部查询)
table 常见类型：
显示这一行的数据是关于哪张表的.
有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
type 常见类型：
对表访问方式，表示MySQL在表中找到所需行的方式，又称“访问类型”。
常用的类型有： ALL、index、range、 ref、eq_ref、const、system、NULL （从左到右，性能从差到好）
possible_keys
指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null）
该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询
key
key列显示MySQL实际决定使用的键（索引），必然包含在possible_keys中
如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，非实际长度，为最大可能长度。
注：不损失精确性的情况下，长度越短越好。
ref
列与索引的比较，表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值。
rows
估算出结果集行数，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数；
extra
该列包含MySQL解决查询的详细信息,有以下几种情况：
(1).Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
(2).Not exists
MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
(3).Range checked for each
Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
(4).Using filesort
看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行；
(5).Using temporary
看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上；
(6).Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候。
(7).Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题。
在写 select 语句的时候，使用 limit, offset 可能就像是我们吃饭喝水一样自然了。
刚开始工作的时候也经常听前辈们教导：使用 limit, offset，当 offset 变大的时候执行效率会越来越低。
相信在前辈们的言传身教，和自己的实战过程中，大家也都知道了为什么会这样。
因为 select 在执行过程中，对于存储引擎返回的记录，经过 server 层的 WHERE 条件筛选之后，符合条件的前offset 条记录，会被直接无情的抛弃，直到符合条件的第 offset + 1 条记录，才开始发送给客户端，发送了 limit 条记录之后，查询结束。
虽然知道了是什么，也知道了为什么，但是我也一直好奇底层是怎么实现的，所以今天我们来扒一扒它的庐山真面目。
先来简单的回顾一下 select 语句中 limit, offset 的语法，MySQL 支持 3 种形式：
在读取数据的过程中，对于符合条件的前offset 条记录，会直接忽略，不发送给客户端，从符合条件的第 offset + 1 条记录开始，发送 limit 条记录给客户端。
所以，server 层实际上需要从存储引擎读取offset + limit 条记录，源码里也是这么实现的，语法解析阶段，在验证了 offset 和 limit 都是大于等于 0 的整数之后，就把 offset + limit 的计算结果保存到一个叫做 select_limit_cnt 的属性里，offset 也会保存到一个叫做 offset_limit_cnt 的属性里。
来到发送数据阶段，此时的记录已经通过了 WHERE 条件的筛选，接下来就是判断这条记录是不是要发送给客户端。
第 1 步
因为 offset 已经保存到offset_limit_cnt 中了，先来判断 offset_limit_cnt 是否大于 0，如果大于 0，这条记录就会被抛弃了，不发送给客户端；如果等于 0，记录就具备了发送给客户端的资格了，然后接着进入 第 2 步 。
第 2 步
来到这一步，记录就具备了发送给客户端的资格了，至于要不要发，就看客户端想不想要它了，而客户端想不想要它，取决于select_limit_cnt 。
所以，在这一步要判断 已发送记录数量 （send_records）和 需要发送记的录数量 （select_limit_cnt）之间的关系，如果已发送记录数量 大于等于 需要发送的记录数量，则结束查询，否则就接着进入第 3 步。
第 3 步
在这里，记录愉快的等待着被发送给客户端。
既然在offset 变大之后，使用 limit, offset 效率越来越低，那应该怎么办呢？对于实战经验丰富的小伙伴来说，这是相当简单了，但是以防万一刚看到本文的小伙伴是刚刚开始用 SQL 写 Bug，所以还是要大概的写一下的。
以一个 SQL 为例：
为了取到 10 条记录，要先找到 8888 条记录，然后取到需要的 10 条，前面 8888 条记录都白找了，太浪费了，可以这样修改一下：
LAST_MAX_ID 是上一次执行 SQL 时读取到的 主键 ID 的最大值，如果是第一次执行语句， LAST_MAX_ID = 0 。
不过这种方案也有个问题，不支持跳着翻页，只支持顺序翻页（就是每次都点 下一页 的这种）。
如果要支持跳着翻页，怎么办？
只用 MySQL 这把锤子显然有点不够用了，还要再找一把锤子（Redis），可以把符合条件的记录的 主键 ID 都读取出来，存入到 Redis 的有序集合（zset）中，用 zset 相应的函数读取到某一页应该展示的数据对应的那些 主键 ID ，然后用这些主键 ID 去 MySQL 中查询对应的数据，从而用两把锤子间接的实现了分页功能。
当然，这个方案也是有适用场景的，比如，这个方案明显就不适用于这些场景：符合条件的记录非常非常多导致存主键 ID 到 Redis 要占用很大的内存、记录更新频繁导致存主键 ID 的缓存经常被清除。如果碰到更复杂的场景，就要结合业务具体情况具体分析了
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）