SQL字段筛选优化的核心是减少数据扫描量、避免隐式转换、善用索引覆盖并走高效执行路径；需明确指定所需字段而非SELECT *，WHERE条件须严格匹配索引顺序与类型，高区分度字段置左、范围查询字段置右。
SQL字段筛选优化的核心，是减少数据扫描量、避免隐式转换、善用索引覆盖，并让查询引擎尽可能走高效执行路径。不是加了WHERE就快，关键在“怎么写”和“为什么这样写快”。
只查需要的字段，别用 SELECT *
SELECT * 会强制读取整行所有字段，即使只显示其中两列。尤其当表里有TEXT、JSON、大VARCHAR或多个冗余字段时，I/O和网络传输开销陡增，还可能让本可走覆盖索引的查询被迫回表。
- 明确列出业务真正需要的字段，例如 SELECT user_id, nickname, status 而非 SELECT *
- 视图或ORM中也要检查是否默认拉全字段，可在日志里看实际生成的SQL确认
- 对宽表（50+列）尤其敏感，少查10个无用字段，性能提升可能超30%
WHERE条件要对齐索引顺序和类型
索引不是“有就行”，而是要和WHERE中的字段顺序、比较方式、数据类型严格匹配。常见失效场景包括：
- 在索引字段上做函数操作：WHERE YEAR(create_time) = 2024 → 改成 WHERE create_time >= '2024-01-01' AND create_time 2025-01-01'
- 隐式类型转换：WHERE mobile = 13812345678（mobile是VARCHAR）→ 改成 WHERE mobile = '13812345678'
- 联合索引顺序错位：INDEX (a,b,c)，但查询写 WHERE b = 2 AND c = 3 → 无法使用该索引，应调整为 WHERE a = 1 AND b = 2 或重建索引
善用覆盖索引，避免回表
当SELECT字段和WHERE条件字段都能被同一个索引“完全包含”时，MySQL/PostgreSQL可直接从索引中取数，无需再查主键聚簇索引——这就是覆盖索引。它大幅减少随机I/O。
- 例如：表有索引 INDEX idx_uid_status (user_id, status)，查询 SELECT user_id, status FROM orders WHERE user_id = 123 AND status = 'paid' 就是典型覆盖
- EXPLAIN中看到 Extra: Using index 表示命中覆盖；若出现 Using where; Using index condition 是索引条件下推，也高效；但出现 Using filesort 或 Using temporary 就需警惕
- 高频查询可针对性建窄索引，宁可多几个小索引，也不盲目加宽单个索引
区分等值与范围，理解最左前缀法则
联合索引本质是按字段顺序排序的B+树。查询能用上多少列，取决于“连续等值匹配”的长度。
- INDEX (a,b,c)：WHERE a=1 AND b=2 AND c=3 → 三列都走索引
- WHERE a=1 AND b>2 AND c=3 → 只有a、b走索引（c因b是范围而失效）
- WHERE b=2 AND c=3 → a缺失，整个索引失效（除非是MySQL 8.0+的跳过扫描，但不推荐依赖）
- 小技巧：把高区分度、高频等值过滤的字段放索引左边，范围查询字段（如时间、状态）尽量靠右
基本上就这些。优化不在炫技，而在理解数据分布、索引结构和执行器行为。每次加WHERE前，先问一句：这个条件能不能走索引？查的字段是不是真需要？执行计划有没有回表或临时表？答得清，速度自然来。
