1. 执行计划不是“看图说话”，而是数据库在向你坦白它的真实想法大多数人第一次点开 DBeaver 的「执行计划」按钮，看到那张带箭头的树状图时，第一反应是：这玩意儿长得像编译器的 AST，但又不像——没有变量名，没有作用域，只有 Nested Loop、Index Scan、Hash Join 这些词反复出现。我试过让三个不同资历的后端同事各自分析同一条慢查询的执行计划，结果：一个说“肯定是没走索引”，一个说“应该是 join 顺序错了”，第三个直接截图发到群里问“这个 cost=124587 是不是代表要等两分钟？”——没人提 buffer hit rate，没人看 rows=1 vs rows=100000 的偏差，更没人注意到 Seq Scan 后面那个 Filter: (status = ‘pending’) 其实正在全表扫描后过滤掉 99.8% 的数据。这就是问题所在：执行计划不是一张静态快照，而是一份动态的、带上下文的“数据库自白书”。它告诉你“我打算怎么干”，但不会主动说“我为什么这么干”、“我干得有多糟”、“你改哪一行 SQL 就能让我少干 90% 的活”。而 AI 编程工具的价值，恰恰在于它能把这份自白书翻译成工程师听得懂的诊断报告，并给出可落地的手术刀式修改建议——不是生成新 SQL，而是告诉你原 SQL 哪里伤了数据库的筋骨，该怎么动刀才不伤元气。这篇文章只讲一件事：如何用 AI 编程工具（不限定某一家，但我会以实测过的 Claude Code、Cursor 和本地部署的 DeepSeek-Coder-32B 为参照）辅助识别四类最具破坏性的慢查询模式。不讲原理推导，不讲优化器源码，只讲你在 DBeaver 里右键点击「
