SQL字段筛选优化的核心是减少数据扫描量、避免隐式转换、合理使用索引并只取所需字段；需避免SELECT *、确保WHERE条件能命中索引、慎用函数和前导通配符LIKE，结合EXPLAIN分析执行计划调优。
SQL字段筛选优化的核心是减少数据扫描量、避免隐式转换、合理使用索引，并让查询尽量“只取所需”。不是加了WHERE就高效，关键看条件是否能走索引、字段类型是否匹配、表达式是否可下推。
只查需要的字段，别用 SELECT *
SELECT * 会读取整行数据，即使只用其中1–2个字段，也会增加I/O和网络传输开销，尤其表里有TEXT、JSON或大字段时更明显。数据库无法跳过无关列，存储引擎仍要加载完整行。
- 明确列出业务真正需要的字段，比如 SELECT user_id, name, status 而非 SELECT *
- 视图或ORM中也要检查生成的SQL，避免底层自动展开成*（如某些框架的“懒加载”配置可能触发）
- 对宽表（30+列）做分页查询时，这点影响尤为显著
WHERE条件要能命中索引
筛选效率高低，80%取决于WHERE子句能否利用索引快速定位。常见失效场景包括：
- 在索引字段上用函数：如 WHERE YEAR(create_time) = 2024 → 改为 WHERE create_time >= '2024-01-01' AND create_time 2025-01-01'
- 隐式类型转换：如 WHERE mobile = 13812345678（mobile是VARCHAR）→ 数字会被转字符串，但MySQL可能不走索引，应写成 WHERE mobile = '13812345678'
- 对索引前导列跳过：联合索引 (a,b,c)，WHERE b = 2 AND c = 3 无法使用该索引；必须包含a或满足最左前缀（如 WHERE a = 1 AND c = 3 可部分使用）
善用覆盖索引，避免回表
当SELECT字段和WHERE条件字段都能被同一个索引“覆盖”，数据库就无需回到主键索引查原始行数据（即避免回表），大幅减少随机I/O。
- 例如查询 SELECT order_id, status FROM orders WHERE user_id = 1001，可建联合索引 (user_id, order_id, status)
- 用 EXPLAIN 查看执行计划，如果 Extra 列显示 Using index，说明命中覆盖索引
- 注意索引宽度：别把大字段（如content TEXT）加进索引，会拖慢写入且占用空间
区分等值与范围，调整索引顺序
联合索引中，等值条件列放前面，范围条件（>,
- 推荐顺序：WHERE a = ? AND b = ? AND c > ? → 索引设计为 (a, b, c)
- 错误示例：WHERE a = ? AND c > ? AND b = ?，虽然逻辑等价，但c在b前出现范围，b列索引失效
- LIKE以通配符开头（LIKE '%abc'）无法走索引，考虑全文索引或倒排表替代
基本上就这些。字段筛选不是拼条件，而是配合数据分布、索引结构和执行路径做协同设计。慢查先看EXPLAIN，再调字段和索引，比盲目加缓存更治本。
