CodeBuddy通过人机协同辅助数据库查询优化全过程。一、上传EXPLAIN执行计划并附SQL，AI识别全表扫描等瓶颈；二、提供具体索引创建语句及SQL改写建议；三、指出隐式类型转换等问题；四、给出索引冗余检查、低风险建索引方式及验证方法。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
CodeBuddy本身不直接执行数据库操作，但能帮你系统性地完成从问题定位到落地优化的全过程。关键在于“人机协同”：它分析、建议、验证，你来确认和执行。
一、上传或粘贴执行计划，让AI看懂瓶颈
这是最精准的起点。把MySQL或PostgreSQL的真实执行计划交给CodeBuddy，它能识别出真正拖慢查询的环节。
- 在数据库中运行
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TRADITIONAL（MySQL），复制完整输出结果 - 在CodeBuddy对话框中粘贴该执行计划，并附上对应SQL语句，例如：
SELECT * FROM orders WHERE status = 'paid' AND created_at > '2026-01-01' - CodeBuddy会指出如
type: ALL（全表扫描）、Extra: Using filesort或Using temporary等关键信号，并说明哪一列没走索引、为什么没走
二、获取可落地的索引与SQL改写建议
它不会只说“加个索引”，而是告诉你加什么、为什么加、怎么加才有效。
- 针对WHERE条件中的等值字段（如
vessel_id）和范围字段（如entry_time），推荐联合索引顺序，例如CREATE INDEX idx_vessel_time ON navigation_orders(vessel_id, entry_time) - 提示你调整SQL写法以匹配索引，比如把
WHERE YEAR(created_at) = 2026改成WHERE created_at >= '2026-01-01' AND created_at - 若存在
ORDER BY字段未被覆盖，会建议将排序字段加入索引末尾，或改用覆盖索引避免额外排序
三、无执行计划时也能做静态推演
即使暂时拿不到执行计划，只要提供建表语句和SQL，CodeBuddy仍能基于规则推理潜在问题。
- 上传
CREATE TABLE语句，包含字段类型、主键、外键定义 - 输入SQL并说明场景，例如：“这个分页查询在500万行表上要跳过前10万条，很慢”
- 它会识别深分页风险，建议改用游标方案（如
WHERE id > ? ORDER BY id LIMIT 20），并提醒你确保id上有索引 - 还能发现隐式类型转换，比如
vessel_id VARCHAR(32)却用WHERE vessel_id = 123，提示改为字符串形式'123'
四、验证与上线前检查
优化不是加完索引就结束，CodeBuddy会帮你预判副作用和验证路径。
- 提醒你检查新索引是否冗余，比如已有
(a,b)索引，再建(a)就是多余 - 建议在非高峰时段执行
CREATE INDEX CONCURRENTLY（PostgreSQL）或使用ALGORITHM=INPLACE（MySQL 5.6+），避免锁表 - 给出验证方法：执行优化后SQL，对比
EXPLAIN中rows是否大幅下降、key是否命中新建索引、Extra是否不再出现Using filesort
整个过程不需要你记住所有优化规则，CodeBuddy把数据库内核逻辑转化成可读建议，你只需按步骤确认、执行、验证。不复杂但容易忽略细节。
