SQL字段筛选优化的核心在于数据访问路径与查询意图表达，需避免SELECT *、按选择率排序复合索引字段、慎用IN列表、规避字段函数操作，并通过覆盖索引和ETL预计算提升效率。
SQL字段筛选优化的核心，不是堆索引或硬写子查询，而是从数据访问路径和查询意图表达两个层面重新理解WHERE条件。下面用一个真实电商订单分析场景拆解关键思维。
别让“SELECT *”毁掉所有优化努力
某次慢查日志显示：单表查询耗时2.8秒，但表仅120万行。EXPLAIN发现Extra列写着“Using where; Using temporary; Using filesort”。排查后发现语句是：
SELECT * FROM orders WHERE status = 'paid' AND created_at > '2024-01-01';问题不在WHERE，而在SELECT * —— 该表有37个字段，含3个TEXT类型和2个JSON字段。每次扫描都要读取整行（含大字段），IO翻倍，内存临时表膨胀。
- 只查真正需要的字段，比如分析只需order_id、user_id、amount、created_at
- 把TEXT/JSON字段单独建宽表或异步落库，主表保持轻量
- 加覆盖索引时，必须把SELECT字段全包含进去，否则仍会回表
复合索引顺序要匹配“筛选强度+排序需求”
原索引是(status, created_at)，但业务中status='paid'占比高达68%，而created_at范围常限近7天（仅0.3%数据）。索引最左前缀失效，实际走了全索引扫描。
优化后建索引：(created_at, status, user_id, amount)
- created_at放最左：时间范围过滤选择率高，快速定位数据段
- status紧随其后：进一步在时间切片内精确过滤
- user_id和amount加入：构成覆盖索引，避免回表查主键以外字段
- 注意：如果后续要ORDER BY created_at DESC，这个索引天然支持，无需额外排序
IN列表别盲目拼接，小心隐式转换和参数爆炸
运营同学导出指定用户订单，代码生成了包含2300多个user_id的IN语句。MySQL 5.7下，IN超过1000项就容易触发执行计划退化；更糟的是，user_id字段是BIGINT，但传参时混入了带引号的字符串，导致全表扫描。
- IN列表超500项，改用临时表JOIN（CREATE TEMPORARY TABLE + INSERT VALUES + JOIN）
- 确保字段类型与参数严格一致：数值型不用引号，字符串字段才加单引号
- 必要时用WHERE user_id BETWEEN a AND b替代离散IN，尤其适用于ID连续场景
函数操作是索引杀手，绕开它才有出路
原始语句：WHERE DATE(created_at) = '2024-03-15' —— 索引完全失效。
正确写法：WHERE created_at >= '2024-03-15 00:00:00' AND created_at
- 所有字段级函数（YEAR()、SUBSTRING()、UPPER()等）都会阻断索引使用
- 日期比较优先用范围，而非DATE()/HOUR()提取
- 真要按周/月统计？提前在ETL层加计算字段（如week_start_date）并建索引
基本上就这些。优化不是调参，是读懂数据分布、理解执行器如何走路、再反向约束SQL写法。每一条慢查背后，都藏着对业务场景的一次重新建模。
