SQL 查询性能与完整性审查

目标与适用范围

围绕查询构建、JOIN、格式化、性能计划、注入风险、外键完整性和 schema 差异，形成可审批的 SQL 审查证据。
本指南将当前任务范围转化为可复核的交付结果。请保留源文件、中间产物和关键判断，让后续协作者能够理解检查了什么以及为什么这样处理。

准备证据并作出选择

• 准备目标 SQL、涉及表、预期结果形态和数据库引擎。

• 在判断性能或安全前，收集 schema DDL、索引、代表性行数和参数绑定规则。

• 明确本次审查面向生产查询、分析 SQL，还是依赖表结构变化的发布改动。

• 决策点: 你是在构建新查询，还是审查已有查询？. 查询还在组装时先用 builder 和 joiner；已有 statement 需要审查时，先格式化，让结构和 diff 可读。

• 决策点: 主要风险是正确性、速度还是安全？. 性能分析和执行计划暴露运行风险，注入检测暴露不安全参数处理，外键与 schema 审查则保护关系完整性。

按步骤完成工作流

1. 梳理查询和 JOIN

从目标表和 JOIN 规则构建或还原 SQL，让审阅者能看清查询意图和业务关系。 使用 sql-query-builder, multi-table-joiner.

2. 规范化 SQL 便于审查

统一格式、对齐子句与别名，让后续 diff、评审意见和审批记录更容易阅读。 使用 sql-query-formatter, sql-formatter.

3. 审查性能和执行计划

分析扫描、排序、JOIN 顺序和估算成本，并在接受优化前可视化执行计划。 使用 sql-performance-analyzer, sql-explain-plan-visualizer.

4. 检查安全与关系完整性

扫描参数使用中的注入风险，校验外键关系，并把 schema 假设与当前结构对比。 使用 sql-injection-detector, data-foreign-key-validator, database-schema-diff, table-schema-generator.

交付前验收结果

• SQL 已格式化且可审阅，每个 JOIN 都对应明确的业务关系。
• 性能发现、执行计划瓶颈和索引假设都有记录。
• 注入风险、外键问题和 schema 差异已经检查并在批准前完成分级。

常见问题

• 为什么同时包含两个 SQL 格式化工具？ 面向查询的 formatter 适合审查单条 statement；通用 SQL formatter 用来保持脚本、diff 和审批材料格式一致。
• 这个工作流会自动修复慢查询吗？ 不会。它提供执行计划、成本、JOIN 和潜在索引证据；最终调优仍需要结合真实数据、数据库规则和人工判断。
• schema diff 和表结构生成为什么属于查询审查？ 当查询依赖新表、变更表或不确定结构时，审查者必须先看到这些结构假设，才能批准 SQL。