索引不能为SELECT字段单独建立，而应针对WHERE、ORDER BY、GROUP BY和JOIN条件中的字段创建；仅优化SELECT列表无法加速查询，除非满足覆盖索引条件。
SELECT 中的字段本身不能直接建索引
索引不是为 SELECT 列表里的字段单独建的，而是为 WHERE、ORDER BY、GROUP BY、JOIN 条件中出现的字段建的。如果你发现某条 SELECT * 查询很慢，只给 SELECT 里的字段加索引毫无作用——数据库不会用它加速读取，因为索引不存完整行数据（除非是覆盖索引，但那是另一回事）。
真正该关注的是：这条慢查询的 WHERE 条件列是否已索引？排序字段有没有索引？关联字段类型和索引是否匹配？
什么时候“SELECT 字段”会影响索引选择？——覆盖索引场景
当一个索引包含查询所需的所有字段（即 WHERE + SELECT 列都在索引里），MySQL/PostgreSQL 可能直接走索引而避免回表，这就是覆盖索引。此时 SELECT 的字段就变得关键了。
- 例如表
t_user(id, name, email, status)，有复合索引(status, name)，而查询是SELECT name FROM t_user WHERE status = 'active'—— 这个索引就能覆盖，不用查主键再回表 - 但如果写成
SELECT name, email FROM t_user WHERE status = 'active'，而索引没包含email，就无法覆盖，仍要回表 - PostgreSQL 对覆盖索引更宽松，支持
INCLUDE子句把非索引字段“附带”进去：CREATE INDEX idx_status_name ON t_user (status) INCLUDE (name); - MySQL 8.0+ 也支持函数索引和部分覆盖能力，但不支持
INCLUDE，得靠联合索引硬凑
频繁查询但无 WHERE 条件？先别急着建索引
如果查询类似 SELECT id, name, created_at FROM t_log LIMIT 1000，没有过滤条件，建任何索引都无效——全表扫描是唯一路径。这时候优化方向完全不同：
- 确认是否真的需要每次查全部 1000 行？能否加时间范围（如
WHERE created_at > NOW() - INTERVAL 7 DAY）让查询可走索引 - 检查表是否过大，考虑归档旧数据（如分区表或按月拆表）
- 评估是否可用物化视图（PostgreSQL）或汇总表（MySQL）预计算常用结果
- 客户端做分页时，避免
OFFSET越大越慢，改用游标分页（基于上一页最后id值）
建索引前必须验证执行计划
不看 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL）就建索引，大概率白忙活。同一个字段，在不同查询中可能走索引，也可能被优化器放弃——取决于数据分布、统计信息、是否用函数包装等。
- 常见陷阱：
WHERE UPPER(name) = 'ALICE'不会用name上的普通索引，得建函数索引：CREATE INDEX idx_name_upper ON t_user (UPPER(name)); - 隐式类型转换会让索引失效，比如
WHERE user_id = '123'（user_id是INT），字符串比较触发全表扫描 - 索引列顺序很重要：
(a, b)可以加速WHERE a = ? AND b = ?，但对WHERE b = ?无效 - 新建索引后记得
ANALYZE TABLE（MySQL）或VACUUM ANALYZE（PG），否则优化器可能还用旧统计
最常被忽略的一点：索引不是越多越好。写多读少的表，每个额外索引都会拖慢 INSERT/UPDATE，还吃内存和磁盘空间。上线前务必在真实数据量下压测写入性能。
