CodeBuddy精准识别全表扫描并提供可落地优化：解析EXPLAIN定位type=ALL/INDEX、key为空、rows过大等问题，推荐按等值→范围→排序顺序创建复合索引，并提示SQL改写避免索引失效。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
遇到全表扫描，核心是让数据库走索引而不是扫整张表。CodeBuddy 能从执行计划识别问题根源，并给出可落地的优化动作，不是泛泛而谈“加个索引”。
先确认是不是真在全表扫描
别只看慢，得看执行计划里的 type 字段：如果显示 ALL 或 INDEX，基本就是全表（或全索引）扫描。CodeBuddy 支持直接解析 EXPLAIN 输出，自动标出这一行并说明影响——比如“扫描 120 万行，预计耗时 842ms”。
- 在 MySQL 中运行
EXPLAIN SELECT * FROM navigation_orders WHERE vessel_id = 'V123'; - 把结果粘贴进 CodeBuddy，它会指出 key 列为空、rows 过大，并关联到缺失索引
- 注意 Extra 字段：出现 Using where; Using filesort 或 Using temporary，往往意味着后续还有性能陷阱
针对性建复合索引（不是随便加）
CodeBuddy 不推荐单列索引堆砌，而是按查询真实条件组合字段顺序。关键逻辑是：等值条件放左，范围条件放右，排序字段可追加。
- 例如查询
WHERE status = 'shipped' AND created_at > '2024-01-01' ORDER BY user_id，它建议建(status, created_at, user_id) - 如果 WHERE 中有
vessel_id IN ('A','B') AND entry_time BETWEEN ...，则优先(vessel_id, entry_time)，而非反过来 - 它会检查现有索引是否冗余——比如已有
(a,b,c)，再建(a,b)就会被标记为“可删除”
改写SQL适配索引（光建索引不够）
很多全表扫描不是没索引，而是 SQL 写法让索引失效。CodeBuddy 会同步提示这类风险并给出等价改写。
- 避免对索引列用函数：
WHERE YEAR(create_time) = 2024→ 改成create_time >= '2024-01-01' AND create_time - 修复隐式类型转换：
vessel_id = 123（字段是 VARCHAR）→ 改为vessel_id = '123' - 拆分 OR 条件：
WHERE a = 1 OR b = 2→ 建议用UNION ALL分开查，各自走不同索引
补统计信息和验证效果
即使索引建对了，如果表统计信息过期，优化器也可能“视而不见”。CodeBuddy 会在建议末尾明确提醒这一步。
- 执行
ANALYZE TABLE navigation_orders;更新统计信息 - 再跑一次
EXPLAIN，确认 type 变为 ref 或 range，key 显示新索引名 - 它还能比对前后 rows 值——比如从 120 万降到 2300，说明索引真正生效
