SQL字段筛选优化的核心是减少数据扫描量、避免全表扫描、合理利用索引，并让查询引擎尽可能快地定位目标行；需只查必要字段、优先高选择性字段建索引、遵守最左匹配原则、善用覆盖索引、避免隐式类型转换和函数操作。
SQL字段筛选优化的核心是减少数据扫描量、避免全表扫描、合理利用索引，并让查询引擎尽可能快地定位目标行。不是字段写得越少越好，而是要让数据库“少读、快判、准取”。
只查需要的字段，别用 SELECT *
SELECT * 会强制数据库读取整行所有列，即使你只用其中1–2个字段。尤其当表里有TEXT、BLOB或大量冗余字段时，I/O和网络传输开销明显上升。
- 明确列出业务真正需要的字段，如 SELECT user_id, name, status 而非 SELECT *
- 视图或ORM中也要检查是否隐式展开了全部字段
- 聚合查询（如 COUNT、SUM）尽量配合 WHERE 提前过滤，而非先查全量再内存处理
WHERE 条件顺序不重要，但字段选择性很关键
现代数据库（MySQL 8.0+、PostgreSQL、SQL Server）会自动重排 WHERE 子句顺序，所以不用手动把“高区分度字段”写在前面。真正影响性能的是字段的选择性（即去重值数量 / 总行数）。
- 优先在高选择性字段上建索引，比如 order_id（几乎唯一）、email；避免在 gender、is_deleted 这类低选择性字段单独建索引
- 组合索引要注意最左匹配原则：索引 (a,b,c) 可用于 WHERE a=1、WHERE a=1 AND b>5，但不能用于 WHERE b=2 或 WHERE c=3
- 对范围查询（>, 10 AND c = 5，c 通常无法走索引
善用覆盖索引，避免回表
当查询字段全部被某个索引包含时，数据库可直接从索引树中拿到结果，无需再回主键索引查找整行数据——这就是覆盖索引，能显著减少随机I/O。
- 例如表有索引 (user_id, status, create_time)，那么 SELECT user_id, status FROM t WHERE user_id = 123 就是覆盖查询
- EXPLAIN 中看到 Extra: Using index 表示命中覆盖索引；若出现 Using where; Using index condition，说明用了索引下推（ICP），也属优化
- 注意：主键本身是聚簇索引，SELECT 主键字段天然高效；但 SELECT * + 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'
- ❌ WHERE UPPER(name) = 'TOM' → 改用函数索引（MySQL 8.0+）或生成列+索引，或应用层统一存大写
基本上就这些。字段筛选不是写法问题，而是数据访问路径的设计问题。索引建对了、字段选精了、条件写稳了，90% 的慢查就能迎刃而解。
