explain显示using index仅说明外层查询走了覆盖索引，子查询是否覆盖需单独验证；子查询字段未被索引覆盖时仍会全表扫描，导致整体性能卡顿，必须确保子查询的where条件和select字段共用同一联合索引且顺序合理。
嵌套查询里子查询字段没被索引覆盖，为什么EXPLAIN还显示Using index？
那只是外层查询走了覆盖索引，不代表子查询也覆盖了。真正卡顿的常是子查询本身——比如SELECT id FROM users WHERE status = 'active'，若status没索引，或id不在索引里，数据库就得全表扫users，哪怕外层orders有完美索引也白搭。
验证方法：对子查询单独EXPLAIN，看Extra是否出现Using index；同时检查rows是否接近表总行数。
-
status字段必须建索引，且类型要和查询值严格一致（比如status VARCHAR(20)不能和'active'隐式转成TEXT） - 子查询
SELECT的字段（如id）必须包含在同一个索引中，不能只索引status就完事 - MySQL里
INDEX idx_status_id (status, id)有效，但INDEX idx_id_status (id, status)大概率失效——顺序错了
PostgreSQL怎么给子查询做覆盖索引？INCLUDE不是万能的
PostgreSQL不支持传统联合索引覆盖WHERE + SELECT双需求，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需大小写不敏感，必须用表达式索引：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，否则索引无法建立或失效。
