嵌套查询在千万级数据下崩溃，主因是执行计划被迫全表扫描或物化临时表；必须用物化视图固化计算结果，并建覆盖索引确保where、子查询及外层join字段全链路命中索引。
嵌套查询在大数据量下卡住，90% 不是语法问题，而是执行计划被迫走全表扫描或临时表 —— 物化视图和覆盖索引不是“可选项”，而是必须介入的两个技术点。
为什么嵌套查询一到千万级就崩？
典型表现是 EXPLAIN 出现 Using temporary; Using filesort，或者 rows 列显示扫描行数远超实际返回行。根本原因不是子查询写得“嵌得太深”，而是外层 WHERE 或 JOIN 条件无法利用索引，导致内层结果集被全量生成后再过滤。
- 子查询返回 50 万行，但外层只取前 10 行 → 数据库仍得先算完全部 50 万行
-
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active')→ 若users.status没索引，或orders.user_id类型不匹配，就会触发全表扫描 - 子查询含
GROUP BY或ORDER BY，但没对应覆盖索引 → 必然落盘临时表
物化视图怎么建才真正生效？
物化视图的核心价值是把“运行时计算”变成“存储时固化”。但直接 CREATE MATERIALIZED VIEW 并不能自动加速所有嵌套场景 —— 它只对明确引用该视图的查询起作用，且刷新策略必须匹配业务时效要求。
- PostgreSQL：用
CREATE MATERIALIZED VIEW mv_active_users AS SELECT id FROM users WHERE status = 'active'，再建索引CREATE INDEX ON mv_active_users(id)；后续查询改写为SELECT * FROM orders WHERE user_id IN (SELECT id FROM mv_active_users) - MySQL：无原生支持，需用定时任务 + 临时表模拟：
CREATE TABLE mv_active_users AS SELECT id FROM users WHERE status = 'active'，配合TRUNCATE + INSERT ... SELECT每日刷新 - SQL Server：必须用索引视图（
CREATE VIEW ... WITH SCHEMABINDING），且查询中必须显式写SELECT * FROM your_indexed_view，加WITH (NOEXPAND)提示才能强制走物理存储 - 关键限制：物化视图里不能有
GETDATE()、RAND()、非确定性函数；基表字段若为计算列，必须PERSISTED
覆盖索引如何覆盖嵌套查询的全链路？
覆盖索引不是给子查询单独建个索引，而是让整个嵌套路径上的字段都落在同一个索引里 —— 包括子查询的 WHERE 字段、SELECT 字段，以及外层查询的 JOIN 或 IN 字段。
- 子查询是
SELECT id FROM users WHERE status = 'active'→ 索引必须是INDEX idx_users_status_id (status, id)，不能只建(id)或(status) - 外层是
SELECT order_no FROM orders WHERE user_id IN (...)→ 还要在orders上建INDEX idx_orders_user_id (user_id)，否则IN查找仍是全表扫 - 如果子查询带
ORDER BY created_at LIMIT 10，而你又想避免排序，索引就得扩展为(status, created_at, id)，让数据天然有序 - 验证是否生效：EXPLAIN 外层查询，看
Extra是否出现Using index，且rows显著下降
最容易被忽略的三个细节
很多团队建了物化视图、也加了索引，但性能没改善，往往卡在这三点：
- 子查询里用了
UPPER(name)或DATE(create_time)→ 索引完全失效，必须提前建生成列或范围条件重写 - MySQL 中
IN (subquery)在 8.0.19+ 才默认启用SEMI-JOIN优化，老版本建议强行改写为EXISTS或JOIN - 物化视图刷新后，统计信息未更新（如 PostgreSQL 的
ANALYZE mv_active_users），优化器仍按旧分布估算，可能弃用视图
