先别急着信EXPLAIN里那个Using index，它只告诉你外层查询走了覆盖索引，子查询这块儿可是个“黑箱”。真正拖慢性能的，往往是子查询自己在里面全表扫描——比如SELECT id FROM users WHERE status = 'active'，要是status没索引，或者id不在索引里，那数据库就得硬着头皮扫整张users表。外层orders索引再好，也救不了它。

怎么验证？简单：把子查询单独拎出来跑一遍EXPLAIN，看看Extra里有没有Using index，同时瞄一眼rows是不是接近表的总行数。如果接近，说明子查询根本没走索引，性能瓶颈就在这儿。

嵌套查询里子查询字段没被索引覆盖，为什么EXPLAIN还显示Using index？

还是那句话：外层查询“作弊”了。子查询自己没覆盖，外表却显示覆盖，因为外层在orders表上利用了索引，但子查询的users表可能正在全表扫描。要命的是，这种问题往往被忽视——你盯着外层索引优化半天，结果慢的是子查询那一步。

那怎么破？三个关键点得咬着不放：

• status字段必须建索引，而且类型要和查询值严格一致。比如status VARCHAR(20)，查询里写'active'没问题，但别搞成隐式转换，比如把字符串和TEXT混着用，索引直接废掉。
• 子查询SELECT的字段（比如id）必须包含在同一个索引中。只给status建索引没用，得把id也塞进去，形成联合索引。
• 索引列的顺序很关键。MySQL里INDEX idx_status_id (status, id)有效，但INDEX idx_id_status (id, status)大概率白搭——顺序颠倒了，status过滤条件用不上。

PostgreSQL怎么给子查询做覆盖索引？INCLUDE不是万能的

PostgreSQL里，INCLUDE是个好工具，但别指望它包打天下。INCLUDE只能挂载非键列，不能用于过滤条件。举个例子：子查询SELECT user_id FROM logs WHERE level = 'ERROR'，你建个CREATE INDEX ON logs (level) INCLUDE (user_id)——level能过滤，但user_id只是附带输出，没法加速IN匹配。真正要覆盖，还得上组合键索引：

• 如果user_id是整型，level是字符串，直接建CREATE INDEX ON logs (level, user_id)，把level放在前面。
• 如果level需要大小写不敏感，得用表达式索引：CREATE INDEX ON logs ((LOWER(level))) INCLUDE (user_id)。注意，INCLUDE列不参与排序，所以子查询里要是有ORDER BY或LIMIT，排序字段必须放在索引前列。

MySQL 8.0+用函数索引覆盖嵌套查询，但别乱套函数

像WHERE YEAR(created_at) = 2024这种写法，哪怕给created_at建了索引也白搭——函数包裹导致索引失效。正确做法是用函数索引固化计算逻辑：

• 建索引：CREATE INDEX idx_year_created ON orders ((YEAR(created_at))) INCLUDE (id)
• 查询必须严格匹配函数形式：SELECT id FROM orders WHERE YEAR(created_at) = 2024
• 别对同一字段反复套函数，比如LOWER(EMAIL)和TRIM(EMAIL)要分开建索引，不能合在一个表达式里。
• 函数索引只在MySQL 8.0+支持，老版本只能靠生成计算列+普通索引硬凑，麻烦但能解。

物化视图引用后仍慢，是不是索引没生效？

物化视图本身不自动带索引，很多人以为建完视图就完事了，结果查询还是慢。PostgreSQL里建完CREATE MATERIALIZED VIEW mv_active_users AS SELECT id FROM users WHERE status = 'active'，必须手动加索引：CREATE INDEX ON mv_active_users (id)。否则外层IN查询还是得全扫描视图表。

更关键的是刷新策略：如果业务允许分钟级延迟，用REFRESH CONCURRENTLY；若要求实时，就得权衡锁表风险。MySQL没原生物化视图，用临时表模拟时，TRUNCATE + INSERT SELECT之后必须ANALYZE TABLE更新统计信息，否则优化器可能误判行数，放弃走索引。

最容易忽略的一点：物化视图基表字段若含计算列，必须声明PERSISTED，否则索引无法建立或失效。这点踩坑的人不少，注意了。