sql字段筛选优化核心是减少扫描量、避免隐式转换、善用索引、精简返回字段；应明确指定所需字段而非select*，where条件需可索引，慎用offset分页，优先limit和游标分页，统计查询注意count语义，复杂逻辑可用cte拆解。
SQL字段筛选优化，核心在于减少数据扫描量、避免隐式转换、善用索引和精简返回字段。不是写得越全越好，而是查得越准越快。
只查需要的字段，别用 SELECT *
SELECT * 会强制数据库读取并传输所有列，即使你只用其中一两个。尤其当表里有TEXT、BLOB或冗余历史字段时，I/O和网络开销明显上升。
- 明确列出所需字段，如 SELECT user_id, name, email 而非 SELECT *
- 视图或ORM中也要检查是否默认拉全量字段，必要时重写查询
- 宽表场景下，少选1个大字段，可能降低30%以上响应时间
WHERE条件要“可索引”，避开陷阱
筛选效率高低，关键看WHERE能否命中索引。但很多写法会让索引失效：
- 避免在索引列上做函数操作：WHERE YEAR(create_time) = 2024 → 改为 WHERE create_time >= '2024-01-01' AND create_time 2025-01-01'
- 避免隐式类型转换：WHERE user_id = '123'（user_id是INT）→ 字符串转数字导致索引失效，应统一类型
- LIKE慎用前导通配符：WHERE name LIKE '%abc'无法走索引；LIKE 'abc%'可以
合理使用覆盖索引，让查询“不回表”
如果WHERE + SELECT 的所有字段，都被同一个索引包含，MySQL就无需回主键索引查数据行——这叫“覆盖索引”，能极大提速。
- 例如：查询 SELECT order_id, status FROM orders WHERE user_id = 1001，可建联合索引 (user_id, order_id, status)
- 注意字段顺序：等值查询字段（=）放最左，范围查询（>, BETWEEN）后不再延伸索引有效长度
- 用 EXPLAIN 看 Extra 列是否含 Using index，确认是否覆盖
小结果集优先，配合 LIMIT 和分页优化
筛选后数据量大，但业务只需前N条？尽早加LIMIT，让优化器选择更优执行路径。
- 带ORDER BY的分页慎用 OFFSET，10万条后偏移效率骤降；改用“游标分页”：WHERE id > last_seen_id ORDER BY id LIMIT 20
- 统计类查询（COUNT）尽量走索引：COUNT(*) 在InnoDB中会选最小二级索引，但 COUNT(字段) 遇到NULL会跳过，需留意语义
- 临时结果太多？考虑用 WITH（CTE） 拆解逻辑，比嵌套子查询更易读且部分场景更优
基本上就这些。优化不是堆技巧，而是理解数据怎么存、查询怎么走、索引怎么用。动手前先 EXPLAIN 一眼，比盲目调写法管用得多。
