子查询WHERE字段无索引必然导致全表扫描；需单独EXPLAIN验证子查询，确保status等值字段有单列或(status,id)组合索引，且类型严格一致，主查询关联字段也须建索引。
子查询的WHERE字段没索引，必然全表扫描
嵌套查询里子查询先执行，如果它的 WHERE 条件字段没索引，数据库只能扫完整张表——哪怕主查询有再好的索引也救不回来。比如 SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active')，若 users.status 没索引，EXPLAIN 会显示子查询的 type=ALL，rows 接近表总行数。
必须单独对子查询 EXPLAIN 验证，不能只看外层。常见错误是只给 status 建了单列索引，但子查询还 SELECT id，这时得建联合索引：CREATE INDEX idx_status_id ON users (status, id)；顺序不能反，否则 status 过滤后无法直接取 id。
-
status字段类型必须和查询值严格一致（如VARCHAR(20)对'active'），隐式转换会让索引失效 - PostgreSQL 不支持用
INCLUDE实现覆盖，必须把user_id放进索引键里：CREATE INDEX ON logs (level, user_id) - MySQL 8.0+ 可用函数索引，但查询写法必须完全匹配，比如建了
INDEX idx_year_created ON orders ((YEAR(created_at)))，就得写WHERE YEAR(created_at) = 2024，不能写成范围条件
主查询关联字段缺失索引，导致双重全表扫描
子查询结果出来后，主查询要用它去过滤或连接。如果主表上没有对应字段的索引，就会再扫一次主表。典型表现是 EXPLAIN 中外层 type=ALL 或 type=index，且 Extra 出现 Using where; Using join buffer。
例如用 IN 时，主表 orders.user_id 必须有索引；用 = 子查询时，同样要确保该字段已索引。别指望数据库自动“聪明”地复用子查询结果——没索引，它就老老实实一行行比对。
- 优先用
EXISTS替代IN，尤其当子查询返回大量值时；但前提是外键字段（如orders.user_id）有索引，否则EXISTS的相关子查询仍可能退化为逐行触发 - 三层以上嵌套必须逐层
EXPLAIN，重点看每层的key列是否非NULL，以及rows是否合理 - 避免在主查询
WHERE中对索引字段做函数操作，比如WHERE UPPER(name) = 'JOHN'，即使name有索引也没用；应改用表达式索引或预计算列
EXPLAIN 显示 Using index ≠ 子查询也覆盖
EXPLAIN 输出中出现 Using index，只代表当前这一层 SELECT 走了覆盖索引，完全不说明子查询有没有走、有没有覆盖。真正拖慢性能的，往往就是那个没被覆盖的子查询。
验证方法很简单：把子查询单独拎出来执行 EXPLAIN，看它的 Extra 是不是也有 Using index，同时检查 rows 是否明显小于表总行数。如果子查询 SELECT id FROM users WHERE status = 'active' 返回 10 万行，但 users 表总共才 12 万行，那基本等于全表扫。
- MySQL 中联合索引字段顺序很关键：
(status, id)有效，(id, status)对WHERE status = ?基本无效 - 子查询里用了
GROUP BY或DISTINCT，对应分组字段也得进索引，否则照样临时表 + 全表扫 - 不要依赖“外层快所以整体快”的直觉——嵌套查询性能是链式依赖，最慢那一环决定上限
函数、类型转换、NOT 等操作让索引彻底失效
在子查询或主查询的 WHERE 里对索引字段用函数、表达式或隐式转换，索引就直接作废。比如 WHERE YEAR(created_at) = 2024、WHERE age/10 = 25、WHERE mobile = 13800138000（mobile 是 VARCHAR），都会触发全表扫描。
这类问题不会报错，但执行计划会诚实暴露：key=NULL，type=ALL。修复方式不是“加索引”，而是改写查询逻辑或使用适配的索引类型。
- 时间范围查询统一改用闭开区间：
WHERE created_at >= '2024-01-01' AND created_at - 不等于条件
!=尽量避免，实在要用可拆成<或>组合，例如status != 'inactive'改为status < 'inactive' OR status > 'inactive'（需确认字段有序） - 隐式类型转换必须杜绝：字符串字段就用引号，数值字段就别加引号；字段定义是
TINYINT就别传'1'
嵌套查询的索引有效性没法靠经验猜，每一层都得用 EXPLAIN 单独验证，尤其是子查询的 rows 和 key。最容易忽略的是：你以为优化了外层，其实瓶颈卡在内层一个没索引的 WHERE 字段上。
