全表扫描不一定是性能问题，小表、低频、单次查询时反而是最优路径；真正危险的是大表+高频+并发叠加场景，需结合rows_examined_per_scan、filtered等真实指标判断。
不一定。全表扫描不是性能灾难的充分条件，而是需要结合数据量、并发、查询频率和系统资源来判断的信号。
关键看 rows_examined_per_scan 和实际业务场景，而不是只盯着 type=ALL。
什么时候全表扫描其实没问题？
小表、低频、单次查询，全表扫描反而是最优路径：
- 表只有几百或几千行（比如配置表、状态字典表），
SELECT * FROM sys_config走全表扫描比走索引还快——因为索引要多一次B+树遍历+回表 - 查询带
LIMIT 1且命中靠前几行，比如SELECT id FROM task_queue WHERE status = 'pending' ORDER BY created_at LIMIT 1，即使没索引，也可能几毫秒返回 - 冷备恢复、ETL初始化加载等离线任务，全表扫描是设计预期，不参与在线服务SLA
什么时候全表扫描就是定时炸弹？
真正危险的是“大表 + 高频 + 并发”三者叠加：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 表行数 ≥ 100 万，
SELECT * FROM order_main WHERE user_id = 123没索引 → 每次查都扫 2.3 亿行（见事故复盘） - 接口QPS > 50，每秒触发几十次全表扫描，磁盘IO打满，其他正常查询排队阻塞
-
log_queries_not_using_indexes = ON但没人看慢查日志，导致问题长期潜伏 - 隐式类型转换让已有索引失效，比如
WHERE phone = 13800138000（phone 是varchar）→ 实际执行变成CAST(phone AS SIGNED) = 13800138000，索引字段被函数包裹
怎么快速判断当前全表扫描是否真危险？
别只跑 EXPLAIN，要看真实执行指标：
- 查
performance_schema.events_statements_summary_by_digest，找rows_examined和rows_sent比值：若比值 > 100（比如扫 10 万行只返回 1 行），基本就是过滤效率崩坏 - 用
pt-query-digest分析慢日志，重点关注Full scan标记 +Rows examine绝对值 - 观察
SHOW GLOBAL STATUS LIKE 'Handler_read%'：Handler_read_rnd_next持续飙升，说明大量随机IO，正在拖垮Buffer Pool
为什么 EXPLAIN 显示 type=ALL 不等于一定慢？
因为 EXPLAIN 只展示优化器“计划怎么做”，不反映真实负载和数据分布：
- 估算
rows常严重失真，尤其统计信息陈旧时（ANALYZE TABLE没跑过） -
filtered字段才是关键：它表示 WHERE 条件实际过滤率，filtered = 0.001意味着 99.9% 的行白扫了 - 有些全表扫描根本没走磁盘——整张表热数据都在 Buffer Pool 里，
innodb_buffer_pool_reads = 0，此时耗时主要在CPU解包和网络传输
真正容易被忽略的点是：全表扫描本身不可怕，可怕的是它掩盖了更深层的问题——比如本该走索引却因类型转换/函数包裹/低选择性而失效，或者查询逻辑本可通过范围缩小就不用扫全表。定位时必须穿透 EXPLAIN 表面，直击 rows_examined_per_scan 和 filtered 这两个真实指标。
