Claude写SQL需提供表结构、字段语义、业务规则和性能安全要求：①表名与主键及外键关系；②关键字段实际取值示例与注释；③过滤逻辑的精确条件与数据陷阱说明；④执行场景、禁止行为及输出格式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
写sql查询时，claude需要知道表结构、字段语义、业务逻辑和数据质量现状，否则生成的sql可能语法正确但查不到真实业务数据，甚至因误判null行为或索引缺失导致超时。必须提供的数据库元信息
第一步：提供表名与主键。例如：users表，主键为id；orders表，主键为order_id，外键user_id关联users.id。没有这张关系图，Claude无法判断JOIN条件是否合理。
第二步：列出关键字段及实际取值示例。比如orders.status不是标准枚举，而是存着'paid'、'shipped'、'cancelled_by_user'三种字符串——若只写“状态字段”，Claude大概率按'pending'/'success'/'failed'生成WHERE条件，结果为空。
【字段注释缺失时，必须人工补全】例如products.code字段，实际是SKU编码（如'A102-BLK-XL'），而非内部系统ID；若不说明，Claude可能当作数字ID做IN (1,2,3)查询，直接报错。
业务规则与隐含约束
方法一：用自然语言描述过滤逻辑背后的决策依据。例如：“只查近90天内创建且未被软删除的订单” → 要同步说明created_at > NOW() - INTERVAL '90 days'且deleted_at IS NULL，不能只说“查最近订单”，因为Claude不知道你们用deleted_at标记软删，也不知道时间范围是按创建时间还是支付时间。
方法二：指出常被忽略的数据陷阱。例如：“用户表里email字段有23%为空，且大小写混存；查询去重时必须用LOWER(TRIM(email))再GROUP BY，否则同一个邮箱会算作多条记录。”
性能与安全硬性要求
第一步：声明查询执行场景。是后台定时任务？还是API接口实时响应？若是后者，必须加一句“响应需在200ms内完成”，Claude才会主动规避SELECT *、拒绝子查询嵌套三层以上、优先考虑覆盖索引字段。
第二步：明确禁止行为。例如：“禁止使用UNION ALL拼接不同来源数据，所有数据必须来自sales库下的三张表”或“不得调用任何存储过程，只允许纯SQL”。【违反此条将导致生产环境SQL注入拦截失败】
第三步：指定输出格式。直接写“只输出可执行的SQL语句，不要解释，不要加```sql代码块，不要带行号”，Claude就不会在结果里夹杂Markdown或分析文字。
