Claude SQL查询提示词背景信息全攻略

想让Claude为你编写SQL查询？常见问题是：语法正确但实际数据返回空或结果错位。根本原因在于Claude不了解表结构、字段值及业务逻辑。要获得可靠结果，必须提供以下关键信息。

基础信息包括：表结构、字段含义、业务逻辑和数据质量。仅说"查订单数据"远远不够，大概率生成看似正确但无查询结果的SQL。更糟糕的是，字段可能包含NULL值或缺少索引，导致查询超时或数据库负载过高。

必须提供的数据库元信息

首先，明确表名和主键关系。例如，users表主键为id，orders表主键为order_id，外键user_id指向users.id。缺少这些关系，Claude无法正确编写JOIN条件——可能误写ON user_id = id导致全表扫描。

其次，提供关键字段的实际取值示例。例如orders.status字段，不要只写"状态字段"。你们系统可能存储'paid'、'shipped'、'cancelled_by_user'，而Claude默认枚举为'pending'/'success'/'failed'。不给出真实值，生成的WHERE条件必然返回空结果。

【字段注释缺失时，必须人工补全】例如products.code字段实际为SKU编码，如'A102-BLK-XL'，而非内部数字ID。不说明清楚，Claude可能当作整数类型写IN (1,2,3)导致错误。因此，即使觉得显而易见，也必须明确描述。

业务规则与隐含约束

方法一很简单：用自然语言描述过滤逻辑背后的决策依据。例如"只查近90天内创建且未被软删除的订单"，需具体说明实现为created_at > NOW() - INTERVAL '90 days'加deleted_at IS NULL。仅说"查最近订单"不够，因为Claude不知道你们用deleted_at标记软删除，也不清楚时间范围基于创建还是支付时间。模糊描述导致模糊SQL。

方法二更关键：指出常见数据陷阱。例如"用户表里email字段有23%为空，且大小写混存。去重时必须用LOWER(TRIM(email))再GROUP BY，否则同一邮箱算多条记录。"将这些写入提示，Claude才能主动避开这些坑。

性能与安全硬性要求

首先，告知Claude查询运行场景：是后台定时任务还是API实时响应？后者需添加"响应应在200ms内"，Claude会自动避免危险操作：不写SELECT *、不嵌套三层以上子查询、优先使用覆盖索引。这句话直接决定API能否在高峰流量下保持稳定。

其次，明确禁止行为。例如"禁止使用UNION ALL拼接不同来源数据，所有数据必须来自sales库下三张表"或"不得调用存储过程，仅允许纯SQL"。【违反此条将导致生产环境SQL注入拦截失败】——安全红线必须提前声明。

最后，指定输出格式。直接说明"只输出可执行的SQL语句，不要解释，不要加```sql代码块，不要带行号"。Claude会给出干净代码，避免夹杂Markdown或多余分析文字，省去手动清理步骤。

说到底，清晰交代这些信息，Claude生成的SQL才能真正在生产环境生效，而非制造更多问题。关键就在于提示词的精心设计。