DeepSeek 写 SQL 的正确用法，是把你手里真实的表结构、字段含义和业务目标交代清楚，让它产出查询语句与优化建议，再由你在测试环境验证后使用。它擅长的是把业务描述翻译成 SQL 逻辑、指出慢查询的常见病灶，不擅长的是了解你库里没告诉它的索引与数据分布，所以「给足上下文＋人工验证」是两条基本原则，缺一条都会在细节处翻车。
从表结构描述到第一条 SQL
起手先给表结构：把建表语句或字段清单发给 DeepSeek，注明主键、常用字段含义与表间关系。提问模板可以是：「订单表 orders 含字段 user_id、amount、created_at，用户表 users 含 user_id、city，求近三十天各城市订单总额」。再给它明确的输出要求：字段命名、排序方式、是否需要去重。描述越具体，第一版语句的可用率越高，省掉来回改写的功夫，这比任何「高级提示词」都管用。
让 SQL 更准的上下文给法
三个信息最影响准确度：数据规模，十万行与十亿行的合理写法不同，注明大概量级；业务口径，「活跃用户」怎么定义、金额是否含退款，口径不说清，语句写对了也算错了业务问题，口径定义举例写进提问，比如「金额以未退款订单为准」，一句顶十句追问；数据库类型，不同数据库的语法细节有差异，写明具体类型与版本。追问时把报错原文贴回去，让它基于报错修正，比重新描述快得多。涉及多表关联的复杂查询，先让它解释关联思路再写语句，思路对了语句才对，顺序别反。
慢查询优化的问法与验证
拿到慢查询后，把执行计划一起给它：EXPLAIN 的输出、表的索引清单、慢日志里的耗时，让它分析瓶颈在哪，输出里重点关注扫描行数与用到的索引，把这两行原样贴给它，分析会比只给语句精准一个档次。常见病灶它能快速指出：全表扫描、索引失效的写法、深分页、查询里对字段做函数计算。优化建议落地前必须验证：先在测试环境跑，对比执行时间与返回结果是否一致，再决定是否采用。可以让 DeepSeek 给出两三版改写方案，例如补索引、改写子查询为关联、调整过滤顺序，分别验证后选在当前场景表现合适的版本，没有一版通吃的答案。
常见错误与排查顺序
高频问题按顺序排查：结果行数不对，先查关联条件与去重逻辑，可以追问它「这句 SQL 在什么情况下会多算或少算」；报语法错误，确认它没有用错方言函数，把数据库版本告诉它重新生成；性能反而变差，检查它建议的索引与现有索引是否冲突，重复索引也是负担。要建立一条纪律：AI 产出的 SQL 一律先在只读环境或事务里验证，涉及删除与更新的语句必须人工确认影响范围后再执行，数据安全没有商量余地。
DeepSeek 写的 SQL 要不要人工再查一遍？
- 它会编造不存在的字段或函数吗？：会在上下文不足时发生，把真实表结构给全、写明数据库版本后风险大幅下降，产出后跑一遍是最可靠的检查。
- 复杂的多表关联语句交给它靠谱吗？：思路层面可靠，细节层面要验证，先让它讲关联逻辑，确认逻辑正确后再核对每一张表的关联键。
- 敏感数据表贴给它分析有风险吗？：字段名与结构可以提供，业务敏感的真实数据不要粘贴，用脱敏样例代替，权限与合规要求以所在组织的规定为准。
