sql扫描行数过大的本质是未有效利用索引或执行计划不合理，优化核心是减少物理访问行数；需用explain analyze等验证真实examined_rows，避免隐式转换、函数包裹字段导致索引失效，建立覆盖索引并规避低效写法。
SQL扫描行数过大，本质是查询没有有效利用索引或执行计划不合理，导致数据库读取远超实际需要的数据行。优化核心在于减少实际访问的物理行数，而非单纯降低返回行数。
确认真实扫描量与瓶颈点
别只看EXPLAIN里的rows估算值——它可能严重失真。优先用以下方式验证：
- 执行
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON+SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%your_sql%'（MySQL 8.0+），查看examined_rows或rows_examined真实值 - 检查是否因隐式类型转换、函数包裹字段（如
WHERE YEAR(create_time) = 2024）导致索引失效 - 观察
key列是否为NULL，或type是否为ALL/index（全表/全索引扫描）
精准建立覆盖索引
不是“给WHERE字段加索引”就完事，要让索引同时满足过滤+排序+返回需求：
- 按
WHERE等值条件字段 →WHERE范围/排序字段 →SELECT中需返回的非主键字段顺序建联合索引 - 例如：
SELECT id, name, status FROM orders WHERE user_id = ? AND create_time > '2024-01-01' ORDER BY amount DESC，推荐索引：(user_id, create_time, amount, id, name, status) - 避免在索引中包含大字段（如
TEXT、长VARCHAR），可用主键回表替代
拆分复杂查询，用中间结果控制规模
当单条SQL涉及多表关联或深层嵌套且扫描量失控时，主动“断开”执行链：
- 先用轻量查询获取关键ID集合（如
SELECT id FROM users WHERE tag = 'vip' LIMIT 1000），再用IN或临时表驱动后续关联 - 对分页深翻场景（如
OFFSET 100000），改用游标分页：WHERE id > last_seen_id ORDER BY id LIMIT 100 - 统计类查询（如
COUNT(*)全表）考虑用近似值函数（APPROX_COUNT_DISTINCT）或维护汇总表
检查并清理低效访问模式
有些写法看似简洁，实则触发灾难性扫描：
-
禁止在索引字段上使用
IS NULL、!=、NOT IN（尤其右值含NULL时）、LIKE '%xxx'——这些基本无法走索引范围扫描 - 避免
SELECT *，只查必需字段；关联时确保关联字段类型、字符集、排序规则完全一致 - 定期用
SHOW INDEX FROM table和information_schema.STATISTICS检查索引区分度，删除长期未被使用的冗余索引
