SQL字段筛选优化关键在精准选字段、用对WHERE条件、避免全表扫描；需精简SELECT列表、为高频过滤字段建合适索引、避免索引字段上运算，性能差异可达百倍。
SQL字段筛选优化，核心不在“写得快”，而在“想得准”——选对字段、用对条件、避开全表扫描，性能差异可能达百倍。别急着背语法，先理清这四个关键概念，后面学索引、执行计划、查询重写就顺了。
一、SELECT列表越精简，IO压力越小
数据库读数据是以“页”为单位（通常是8KB），哪怕你只想要1个INT字段，如果SELECT *，它可能得把整行20个字段（含TEXT、JSON）全读进来再丢弃。这不是浪费CPU，是实打实的磁盘IO和内存带宽消耗。
- 永远用具体字段名，比如 SELECT user_id, nickname, created_at，而不是 SELECT *
- 避免在SELECT中做计算或函数（如 UPPER(name)、DATE(created_at)），除非真需要；这些操作会阻止索引下推，也增加CPU开销
- 大文本/二进制字段（如 content、avatar_blob）单独查，或用延迟加载策略（先查主键，再按需取详情）
二、“WHERE条件”的顺序不重要，但字段选择和写法决定能否走索引
很多人以为“把等值条件写前面，范围条件放后面”能加速，其实MySQL/PostgreSQL的优化器会自动重排条件顺序。真正关键的是：这个字段有没有索引？条件能不能被索引覆盖？写法是否让索引失效？
- 优先给高频过滤字段建索引，比如 WHERE status = 'active' AND city = 'shanghai'，status和city都应考虑联合索引（注意顺序：等值字段在前，范围字段在后）
- 避免在索引字段上做运算或函数：WHERE YEAR(create_time) = 2024 → 改成 WHERE create_time >= '2024-01-01' AND create_time 2025-01-01'
- 慎用 NOT IN、!=、NOT LIKE，它们通常无法使用索引；可用 EXISTS 或反向范围替代（如 status != 'deleted' → status IN ('active','pending')）
三、NULL判断要小心，它天然不走B+树索引的等值查找路径
普通B+树索引默认不存储NULL值（MySQL MyISAM除外），所以 WHERE col IS NULL 很可能触发全表扫描。不是语法错，是索引设计没覆盖。
- 业务上能避免NULL尽量避免，用默认值（如 ''、0、'unknown'）替代
- 真需要查NULL，且频率高，可建函数索引（MySQL 8.0+）：CREATE INDEX idx_col_null ON t ((col IS NULL))，或加一个计算列并索引
- 联合索引中，如果最左字段允许NULL，会影响整个索引的选择性，建索引前用 SELECT COUNT(*), COUNT(col), COUNT(*)-COUNT(col) FROM t 看NULL占比
四、用EXPLAIN不是为了“看懂所有字段”，而是盯住三件事
每次写完WHERE + SELECT，花10秒跑一遍EXPLAIN，只看三项：type是否到range以上、key是否用了预期索引、rows是否明显小于表总行数。其他字段（比如key_len、Extra）先放一边。
- type = ALL → 全表扫描，立刻检查WHERE字段有没有索引、写法是否规范
- key = NULL → 没用上索引，不是没建，很可能是隐式类型转换（如字符串字段传数字：WHERE mobile = 13800138000）
- rows远大于实际返回数 → 索引选择性差（比如性别字段只有'男''女'，建索引意义不大），或者统计信息过期（可执行 ANALYZE TABLE t）
基本上就这些。字段筛选不是炫技，是权衡——多选一个字段、多加一个条件，背后都是IO、内存、CPU的账。理清这四点，再去看执行计划、索引优化、慢查分析，就不会迷失在术语里了。
