子查询内部字段无法建索引，因其为内存临时结果集，无物理存储结构，数据库不支持对(SELECT...)创建索引；即使原表有索引，子查询输出仍是无索引的扁平行集。
子查询内部字段无法建索引，因为派生表没有物理存储结构
子查询（尤其是 FROM 中的派生表）执行时生成的是内存临时结果集，不是真实表，也没有磁盘上的 .ibd 文件。数据库不会、也不能为它创建索引——CREATE INDEX 语法根本不支持对 (SELECT ...) 这种表达式操作。
常见误解是“我在子查询里加了 WHERE status = 'active'，又给原表 status 字段建了索引，那子查询结果自然带索引”，但实际只是原表扫描被加速了，子查询输出后仍是无索引的扁平行集。
- MySQL 8.0+ 对简单物化派生表会尝试自动优化（如列裁剪、条件下推），但不等于“有索引”
- PostgreSQL 的
MATERIALIZEDCTE 也仅控制物化时机，仍不可手动加索引 - 想验证：执行
EXPLAIN，看type是derived还是ref；若key为空，说明没走索引下推
外层 JOIN 派生表时 dept_id 匹配慢，根本原因不是缺索引而是无索引上下文
写法如 SELECT * FROM (SELECT id, name, dept_id FROM employee WHERE status = 'active') AS e JOIN dept d ON e.dept_id = d.id，性能瓶颈不在 e.dept_id —— 它压根不是可索引对象，而在于 MySQL 必须对整个派生表 e 做嵌套循环扫描，每次拿 e.dept_id 去查 d 表。
即使 d(dept_id) 有索引，e 侧仍无过滤能力。如果 e 返回 10 万行，就要跑 10 万次索引查找。
- 正确解法是把关联逻辑提到外层：用
JOIN替代派生表，让优化器有机会用employee.status和dept.dept_id联合驱动 - 或提前聚合：把
employee按dept_id分组统计后作为派生表，至少减少行数 - 避免在派生表里
SELECT *，只选真正需要的字段，降低物化开销
标量子查询里 user_id 字段有索引，为什么 COUNT(*) 还很慢？
标量子查询如 (SELECT COUNT(*) FROM order WHERE user_id = u.id)，哪怕 order(user_id) 有单列索引，也可能退化成全索引扫描——因为缺少第二字段支撑覆盖查询。
COUNT(*) 不需要回表取数据，但优化器仍需遍历所有匹配 user_id 的索引项。如果 user_id 选择性差（比如大量用户订单数为 0 或 1），索引范围扫描成本就高。
- 必须建联合索引：
CREATE INDEX idx_user_orders ON order (user_id, order_id)，用order_id占位实现索引覆盖，避免统计时扫描整棵 B+ 树 - 更稳方案是预聚合：用
LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM order GROUP BY user_id) o ON u.id = o.user_id，把 N+1 变成 1 次聚合 + 1 次 Hash Join - 注意：如果
u.id没主键或唯一约束，外层扫描可能无法利用索引下推，子查询执行次数会爆炸
为什么 EXPLAIN 显示 type=ALL，却说“子查询用了索引”？
这是最容易被误导的点：EXPLAIN 的 type 和 key 只反映**当前行对应的操作节点**是否用了索引，不是全局判断。一个查询含多层子查询时，每个子节点单独评估。
例如 SELECT (SELECT COUNT(*) FROM order WHERE user_id = u.id) FROM users u，EXPLAIN 主体显示 users 表是 type=ALL（全表扫描），但子查询那一行可能显示 type=ref, key=idx_user_orders——这仅代表子查询内部走了索引，不改变外层全扫的事实。
- 务必逐行看
EXPLAIN输出，重点关注每条id相同的子查询记录的type/key/rows - 不要只盯着第一行；子查询性能恶化往往藏在
id更大的行里 - 复杂嵌套建议拆成 CTE 或临时表，让
EXPLAIN结构更线性，避免作用域和执行顺序干扰判断
