select_type字段用于识别子查询类型：subquery为非相关子查询，derived表示from中物化临时表的子查询，dependent subquery是相关子查询，外层每行触发一次执行，属性能杀手，需优先优化。
看 select_type 字段识别子查询类型
MySQL 的 EXPLAIN 输出中，select_type 直接暴露子查询是否存在及其嵌套层级。常见值有：SUBQUERY（WHERE 或 SELECT 列表里的非相关子查询）、DERIVED（FROM 子句中的子查询，会物化为临时表）、DEPENDENT SUBQUERY（相关子查询，外层每行都触发一次执行）——这是性能杀手，必须优先关注。
如果看到多个 DEPENDENT SUBQUERY，尤其伴随高 rows 值，说明该子查询被反复执行，扫描量呈乘积级放大。例如外层扫描 10 万行，子查询平均扫描 500 行，实际 I/O 就是 5000 万行。
type 为 ALL 或 index 时子查询大概率低效
子查询对应的 table 行若显示 type: ALL，代表它在每次调用时都在做全表扫描；如果是 type: index，说明走了索引但没用上索引的查找能力（仅遍历索引树），仍属低效。
- 检查子查询的
WHERE条件是否用了索引字段，且未发生隐式类型转换或函数包裹（如WHERE DATE(create_time) = '2024-01-01'） - 确认子查询中
ORDER BY/LIMIT是否能利用索引，否则可能触发文件排序（Extra: Using filesort） - 若子查询含
DISTINCT或GROUP BY，观察Extra是否出现Using temporary—— 这意味着内存/磁盘临时表开销
对比 key 和 possible_keys 判断索引是否被误用
子查询行中，如果 possible_keys 显示有可用索引，但 key 为 NULL，说明优化器放弃使用索引，原因通常是：
- 子查询条件中用了不等号（
!=、NOT IN），尤其当右侧含NULL时，NOT IN会整体失效 - 连接字段类型不一致（如
users.id是BIGINT，而子查询中关联的logins.user_id是VARCHAR） - 子查询返回多列，但只用其中一列参与关联，导致无法命中复合索引最左前缀
此时 rows 常远高于预期，比如本应扫几千行却显示几十万。
用 EXPLAIN FORMAT=JSON 查子查询实际执行策略
EXPLAIN 默认输出对子查询隐藏细节，加 FORMAT=JSON 能看到更真实的执行路径：
EXPLAIN FORMAT=JSON SELECT * FROM users WHERE id IN (SELECT user_id FROM logs WHERE event='login');
重点看 "query_block": {"select_id": 2, "table": {"access_type": "ref", ...}} 部分 —— 它告诉你子查询是否被重写为半连接（semijoin），或是否真的生成了临时表（"using_temporary_table": true）。MySQL 5.7+ 对部分 IN 子查询会自动转为半连接，但 NOT IN 或含 OR 的子查询往往逃不过临时表。
真正容易被忽略的是：即使 EXPLAIN 看起来“走了索引”，只要子查询被标记为 DEPENDENT，它的执行代价就不是静态的，而是随外层数据量线性甚至指数增长。别只盯着单次 rows，要看它被调用了多少次。
