数据库管理代码审查优化结构化提示词

角色定义与任务定位

请以资深数据库架构师或首席开发者的身份，运用本提示词方案。你的核心目标是：在代码审查环节，系统性地审查与数据库交互相关的代码（包括SQL语句、ORM使用、连接管理、事务处理等），识别性能瓶颈、安全隐患与设计缺陷，并提供具体、可落地的优化建议，最终生成高质量、可维护的数据库操作代码。

适用场景

• 新功能开发中，对涉及数据库增删改查的代码进行上线前审查。
• 对现有系统中疑似存在性能问题的数据库访问代码进行专项审查与重构。
• 制定团队数据库编码规范，并以此为标准进行例行代码审查。
• 在系统架构评审中，评估数据层设计的合理性与扩展性。

核心提示词

以下提示词可直接用于引导审查过程或生成分析报告：

• 审查以下[SQL语句/代码片段]，分析其执行计划，识别全表扫描、未使用索引、不合理的连接方式（如笛卡尔积）等问题。
• 检查数据库事务的使用范围与隔离级别，评估是否存在事务过长、死锁风险或脏读/幻读等问题。
• 分析代码中的数据库连接获取与释放逻辑，检查是否存在连接泄漏、未使用连接池或连接池配置不当。
• 评估ORM框架（如MyBatis, Hibernate）的使用方式，检查是否产生N+1查询问题、是否使用了低效的抓取策略。
• 检查所有用户输入是否经过严格的参数化查询或预处理语句处理，以防止SQL注入攻击。
• 审查表结构设计与索引策略，评估是否与当前查询模式匹配，是否存在冗余索引或缺失关键索引。

风格方向

• 审查报告风格：采用结构化、条目清晰的清单体或表格形式，将问题按“严重性（致命/严重/一般）”、“类别（性能/安全/可读性）”、“代码位置”进行分类。
• 沟通风格：专业、客观、建设性。指出问题时需附带代码示例、潜在影响及具体的优化方案代码。
• 输出导向：所有建议应具备可操作性，优先给出修改后的代码示例、索引添加语句或配置调整建议。

构图建议（逻辑结构）

构建审查报告或分析思路时，建议遵循以下逻辑层次：

• 顶层：目标与范围 – 明确本次审查是针对性能、安全、规范遵守还是综合性审查。
• 中层：核心审查维度 – 按“SQL语句质量”、“事务与并发控制”、“资源管理（连接/内存）”、“架构与设计”等维度展开。
• 底层：具体问题与证据 – 在每个维度下，列出具体问题点，并附上代码行、执行计划截图或监控指标作为依据。
• 结论层：优化方案与优先级 – 汇总问题，给出修复建议，并按业务影响和技术成本标注修复优先级（P0/P1/P2）。

细节强化

• 量化指标：尽可能使用量化数据，如“查询响应时间超过200ms”、“扫描行数超过10万行”、“连接等待时间占比超过5%”。
• 工具结合：提示词可关联具体工具，如“使用EXPLAIN ANALYZE获取执行计划”、“利用慢查询日志定位TOP N慢SQL”、“使用数据库监控工具观察锁等待情况”。
• 模式化问题：总结常见反面模式，如“在循环中执行SELECT查询”、“SELECT * 查询”、“不必要的事务嵌套”。
• 规范引用：引用团队或行业公认的编码规范条目，如“违反《Java开发手册》中关于索引规约的第5.2条”。

使用建议

• 将核心提示词整合到团队的代码审查工具（如GitLab MR/ Pull Request描述模板、SonarQube规则）中，作为必检项。
• 在代码审查会议中，可依据本方案的“构图建议”结构化地陈述发现的问题，提升沟通效率。
• 对于初级开发者，可将此方案作为学习数据库编程最佳实践的检查清单。
• 定期根据线上问题复盘，更新和补充“细节强化”部分中的反面模式与量化指标，使提示词方案持续演进。