全表扫描根本成因是查询条件未命中索引、统计信息陈旧或隐式类型转换；需依序检查EXPLAIN的type/key字段、验证WHERE索引失效情形、核查统计信息新鲜度、模拟索引覆盖路径、捕获运行时I/O行为。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
如果您在使用DeepSeek辅助进行SQL性能调优时，已获取到EXPLAIN执行计划但无法准确识别全表扫描（Full Table Scan）的根本成因，则可能是由于查询条件未命中索引、统计信息陈旧或隐式类型转换导致优化器放弃索引。以下是针对该问题的多种分析与验证方法：
一、检查EXPLAIN输出中type字段与key字段组合
MySQL/PostgreSQL兼容的EXPLAIN结果中，type为ALL且key为NULL是全表扫描的直接标志；需结合possible_keys与rows评估实际扫描行数是否异常膨胀。此步骤用于确认是否真实发生全表扫描，排除EXPLAIN误读可能。
1、将原始SQL语句粘贴至数据库客户端，执行EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）获取结构化执行计划。
2、定位最外层节点或扫描节点，检查type列值是否为ALL、type列是否为Seq Scan（PostgreSQL），同时确认key列是否为空或为NULL。
3、若rows估算值远超表总行数的10%，则表明优化器预期扫描范围失控，需进一步排查谓词有效性。
二、验证WHERE条件是否存在索引失效情形
即使存在索引，若查询条件触发前导列缺失、函数包裹、类型隐式转换或OR逻辑分支未覆盖索引列，均会导致索引不可用。该方法聚焦于SQL写法层面的结构性缺陷。
1、提取WHERE子句中所有过滤字段，对照表上现有索引定义，确认每个单字段或组合索引的最左前缀是否被完整用于等值匹配。
2、检查字段右侧是否出现函数调用，例如WHERE YEAR(create_time) = 2024，此类写法强制对每行计算函数结果，无法利用create_time索引。
3、检查字段比较是否发生隐式类型转换，例如VARCHAR字段与整数常量比较：WHERE user_id = 12345，而user_id实际为字符串类型，将触发逐行CAST操作。
三、核查表统计信息新鲜度与采样精度
过期或低精度的统计信息会使优化器误判数据分布，错误选择全表扫描而非索引访问路径。该方法适用于数据批量导入后未及时更新统计信息的场景。
1、执行SHOW INDEX FROM table_name查看索引基数（Cardinality）是否显著偏离实际唯一值数量。
2、运行ANALYZE TABLE table_name（MySQL）或 ANALYZE table_name（PostgreSQL）强制刷新统计信息。
3、对比ANALYZE前后EXPLAIN的type与rows变化，若type由ALL转为ref/range且rows下降两个数量级以上，则证实统计信息为根因。
四、模拟索引覆盖路径并强制Hint验证
通过人工构造覆盖索引或使用优化器Hint，可验证当前执行计划是否受限于索引设计缺陷而非数据特性。该方法用于区分“不能走索引”与“不愿走索引”两类问题。
1、基于SELECT字段与WHERE条件，创建联合索引，确保WHERE等值字段为最左列，SELECT所需字段全部包含在索引列中。
2、在原SQL前添加USE INDEX (index_name)或FORCE INDEX (index_name)提示（MySQL），或使用/*+ IndexScan(table_name index_name) */（PostgreSQL via pg_hint_plan）。
3、重新执行EXPLAIN，观察type是否变为range/ref，key是否显示指定索引名，若此时执行计划变更且rows骤降，则证明原索引缺失或设计不当。
五、捕获实际运行时I/O与缓冲区行为
EXPLAIN仅反映预估计划，真实I/O压力需依赖运行时指标佐证。该方法用于识别“计划正确但物理读激增”的隐蔽瓶颈，例如缓冲池不足导致索引页频繁换入换出。
1、启用慢查询日志并设置long_query_time=0，捕获该SQL完整执行过程的Query_time、Lock_time、Rows_sent、Rows_examined。
2、在MySQL中执行SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_sql%'，提取TIMER_WAIT与LOCK_TIME占比。
3、在PostgreSQL中启用track_io_timing=on后执行EXPLAIN (ANALYZE, BUFFERS)，重点比对shared read与shared hit次数，若shared read占比超过70%且Buffers: shared hit为0，则说明索引页未驻留内存，非计划问题而是缓存配置问题。
