SQL 压缩

应用内嵌 SQL、强调体积控制

建议选：仅对单条查询做保守压缩，降低传输和打包体积。

谨慎用：避免激进重写破坏 Hint、注释语义和语句边界。

排障、审计与长期维护

建议选：仓库保留格式化 SQL，确保评审和 diff 可读性。

谨慎用：避免只存压缩版 SQL 导致可维护性下降。

把稳定只读查询打包进前后端资源

建议选：先通过结果快照与计划校验，再做压缩入包。

谨慎用：不要“先压后测”，避免定位回归成本暴涨。

性能调优、事故复盘、同伴评审

建议选：保留格式化 SQL 与上下文注释，提高沟通效率。

谨慎用：不要用压缩 SQL 直接做复杂排障。

本地探索与临时诊断

建议选：使用快速处理并配轻量验证。

谨慎用：避免把探索结果直接升格为生产产物。

生产发布、合规留痕或跨团队交付

建议选：采用分阶段流程并保留验证记录。

谨慎用：避免无可回放证据的一步执行。

注释清理误删优化器 Hint

失败输入：压缩时把 `/*+ INDEX(...) */` 这类注释式 Hint 一并移除。

失败表现：执行计划漂移，发布后查询延迟突增。

修复：使用能保留 Hint 的 SQL 感知压缩模式，并在上线前做执行计划回归。

多语句脚本压缩后分隔边界失真

失败输入：迁移脚本多条语句被压成一段，分号/分隔规则未被正确保留。

失败表现：解析失败或执行边界错乱。

修复：多语句脚本优先不压缩，或启用严格分隔符保留策略。

压缩时误删优化器 Hint

失败输入：关键查询里的 `/*+ INDEX(...) */` 被当普通注释移除。

失败表现：执行计划退化，发布后延迟显著上升。

修复：对含 hint 的语句保留策略，并在压缩前后做执行计划对比。

多语句脚本压成一行后被驱动拒绝

失败输入：`ALTER ...; UPDATE ...;` 通过禁用 multi-statement 的连接执行。

失败表现：迁移只成功一部分，环境状态不一致。

修复：按语句拆分并用迁移框架按阶段执行。

输入假设未归一化

失败输入：边界载荷缺少必填字段。

失败表现：本地看似通过，但在下游消费阶段失败。

修复：导出前统一契约并强制执行预检。

兼容边界未显式声明

失败输入：一步执行绕过了复核检查点。

失败表现：同一源数据在不同环境得到不一致结果。

修复：明确兼容约束，并用独立消费端回归验证。