SQL字段筛选优化的核心是减少数据扫描量、避免全表扫描、合理利用索引并精简返回字段；应明确指定所需字段而非使用SELECT *，WHERE条件需避免函数操作以确保索引生效，分页宜用游标或时间戳方式。
SQL字段筛选优化的核心是减少数据扫描量、避免全表扫描、合理利用索引，并精简返回字段。不是查得越多越好，而是查得越准越快。
只查需要的字段，别用 SELECT *
SELECT * 会强制数据库读取并传输所有列，即使前端只用其中两三个字段。这浪费I/O、内存和网络带宽，尤其当表里有TEXT、BLOB或大量冗余字段时更明显。
- 明确写出所需字段，例如 SELECT user_id, username, status 而非 SELECT *
- 视图或ORM中也要检查是否隐式生成了 * 查询
- 在聚合或分页场景下，* 还可能干扰执行计划，导致索引失效
WHERE条件要走索引，避免函数操作
筛选效率取决于能否命中索引。一旦在索引字段上做函数运算或类型转换，索引基本就失效了。
- ✅ 好写法：WHERE create_time > '2024-01-01'（假设 create_time 有索引）
- ❌ 慎用：WHERE DATE(create_time) = '2024-01-01'（触发全表扫描）
- ✅ 替代方案：WHERE create_time >= '2024-01-01' AND create_time
- 注意隐式转换，比如字符串字段用数字比较：WHERE phone = 13800138000 可能导致索引失效
善用覆盖索引，让查询“不用回表”
覆盖索引是指：查询所需的所有字段（SELECT + WHERE + ORDER BY + GROUP BY 中涉及的字段）都包含在同一个索引中。这样数据库只需扫描索引树，无需再回主键索引查数据行。
- 例如常用查询：SELECT order_id, status, amount FROM orders WHERE user_id = ? ORDER BY create_time DESC
- 可建联合索引：INDEX idx_user_time (user_id, create_time DESC, order_id, status, amount)
- 注意字段顺序：等值过滤字段（user_id）放最前，范围/排序字段（create_time）居中，查询字段（order_id等）放最后
区分场景，合理使用 LIMIT 和分页优化
深度分页（如 LIMIT 100000, 20）性能差，本质是数据库仍要跳过前10万行。大偏移量下，即使有索引也慢。
- ✅ 推荐游标分页：WHERE id > last_seen_id ORDER BY id LIMIT 20
- ✅ 或基于时间戳分页：WHERE create_time
- 避免在高并发列表页直接用 OFFSET，尤其配合 COUNT(*) 总数统计时
基本上就这些。字段筛选不是语法问题，而是数据访问路径的设计问题。从“我要什么”，倒推“数据库怎么最快给我”，优化自然就清晰了。
