SQL字段筛选优化的核心是只查所需字段并合理设计索引、条件顺序与数据类型；避免SELECT *和WHERE中对字段使用函数，否则导致索引失效、全表扫描。
SQL字段筛选优化的核心，是只查需要的字段，不查多余的，同时配合索引、条件顺序和数据类型合理设计。盲目 SELECT * 或在 WHERE 中滥用函数，是最常见的性能杀手。
避免 SELECT *，明确指定字段
全字段查询不仅增加网络传输开销，还会让数据库无法有效利用覆盖索引，甚至拖慢 JOIN 和排序。
- ✅ 好写法：SELECT user_id, username, status FROM users WHERE status = 'active'
- ❌ 避免写法：SELECT * FROM users WHERE status = 'active'（尤其表有 20+ 字段或含 TEXT/BLOB）
- ? 小技巧：用视图或应用层映射封装常用字段组合，避免每次手写重复列表
WHERE 条件要“可索引”，别让函数/表达式挡路
对字段加函数（如 DATE(created_at)、UPPER(name)）会导致索引失效——数据库只能全表扫描。
- ✅ 可走索引：WHERE created_at >= '2024-01-01' AND created_at
- ❌ 索引失效：WHERE DATE(created_at) = '2024-01-15'（哪怕 created_at 有索引）
- ✅ 替代方案：用范围代替函数；日期类字段优先用 DATETIME 类型 + 范围查询
高频筛选字段必须建索引，但别乱建
索引不是越多越好。重点覆盖 WHERE、JOIN、ORDER BY、GROUP BY 中频繁出现的字段组合。
- ✅ 推荐场景：WHERE status = ? AND category_id = ? ORDER BY created_at DESC → 建联合索引 (status, category_id, created_at)
- ⚠️ 注意顺序：等值条件（=）放前面，范围/排序字段放后面；status 和 category_id 是等值，created_at 是排序，符合最左前缀原则
- ❌ 慎用单列索引堆砌：status 索引 + category_id 索引 ≠ 联合查询高效，可能只用上一个
小字段 + 合理类型，减少 I/O 和内存压力
字段类型影响磁盘读取、缓冲区占用和比较效率。筛选快的前提是数据本身“轻”。
- ✅ 用 TINYINT(1) 存状态码（0/1），别用 VARCHAR(10) 存 'active'/'inactive'
- ✅ 枚举类字段优先用 ENUM 或 CHECK（MySQL 8.0.16+）或关联字典表，避免字符串模糊匹配
- ✅ 大文本（如 content、remark）单独拆到扩展表，主表只留关键筛选字段
基本上就这些。不复杂，但容易忽略——多数慢查询问题，改一两个字段写法或加一个联合索引就能明显提速。
