企业如何做好SQL质量管理？

SQL 操作数据库对应软件研发人员是一类基础且常见的工作内容。如何避免 “问题” SQL 流转到生产环境，保证数据质量？这值得被研发/DBA/运维所重视。

1什么是 SQL 问题？

对于研发人员来说，在日常工作中，大部分都需要使用数据库。项目中的很多业务都需要进行增删改查等常见数据库操作，这些数据库操作对应的 SQL 语句主要都是由开发人员编写的。对于 DBA 来说，作为数据库管理和运维人员，DBA 负责数据库的日常运维工作。当出现问题 SQL 时，DBA 通常首当其冲负责问题诊断。

那么，什么是 SQL 问题或者说问题 SQL 呢？从一个更广泛的定义来看，SQL 问题指影响业务正常运行的各种 SQL 相关问题。比如图上举例的案例，它们都可以被归类为 SQL 问题。爱可生作为一家数据库公司，我们从客户那里获得了大量的反馈，每年都会因为 SQL 问题导致几起高级别的生产事故。类似的 SQL 问题导致业务中断的新闻也时不时会出现。

对研发人员来说，这些 SQL 问题在开发阶段很难被发现，因为研发的首要任务是保证需求实现。此外，按我们对研发人群和客户的调研结果显示，研发人员在新功能开发阶段通常没有时间对 SQL 进行优化，往往只要能完成需求交付就已经很不错了。一方面是项目进度压力大，另一方面研发人员自身水平和经验也有高有低。所以研发人员很难对所有的 SQL 全面进行优化。下面我们举一个真实且典型的案例。

2一个典型的 SQL 问题案例

图中有三张表，请注意表的字符集的不同，分别是 UTF8 和 UTF8MB4。

我们将三张表两两进行联合查询时，分为字符集一致和不一致两种情况。

当字符集不一致时，从执行计划中可见进行了全表扫描，表关联字段未命中索引。

当每张表有 80 万条测试数据时，执行时间差异明显，字符集不一致的 SQL 执行时间达到了 0.9 秒。随着数据量的增加，该 SQL 的问题会愈加明显，两表联查时表的字符集不匹配会导致查询效率大幅下降。这就是一个典型的 SQL 问题。

可能你会觉得本案例的 SQL 问题看似不该发生，但我们的团队曾多次在客户的生产环境中遇到过类似的情况。但根据大家所掌握的慢 SQL 优化习惯来看，有些引发问题的因素是反直觉的。就本案例也不一定会立刻将问题定位和排查出来。所以，我们需要一种更高效的方式来帮助研发人员解决这类问题。

3全方位提高 SQL 质量

SQLE[1]是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升 SQL 上线效率，提高数据质量。

SQLE 于 2021 年 10 月 24 日这个属于开发者的日子正式开源，至今已经两年多。我们保持每个月发布新版本的频率，不断更新和迭代产品功能。

前面的典型 SQL 问题案例，在 SQLE 中如何解决呢？

根据上图可见，SQLE 会在相同的情况下触发审核规则，快速准确的给出审核结果。

在 SQLE 中有非常丰富的 SQL 规则，上面的案例触发了索引失效类规则中的一条。通过制定一套完善的 SQL 规则规范，是做好 SQL 质量管理的第一步。

4做好 SQL 质量管理的第一步
4.1 如何设计 SQL 规范？

在不同的公司和业务场景下，对 SQL 规范都会有不同的要求。想要设计一款通用的 SQL 质量管理平台，对于 SQL 规范的设计要做到按需配置。支持通过规则模板给不同的业务配置不同的规则集。不同的规则集应该有分级匹配机制，以避免触发多条规则产生不同的判断，人为对更严重的问题优先处理整改。在日常工作中也同样允许对特例的 SQL 不进行处理，通过白名单的机制跳过 SQL 审核。

4.2 质量如何量化？

在规则完善后，我们也需要对 SQL 质量处理效果，给人进行量化展示。比如：给 SQL 评分、出《审核报告》和《统计报表》等。一些管理人员并不关心具体的业务，可以通过量化展示，让他们快速了解项目的整体 SQL 质量趋势。

4.3 问题如何优化？

当我们通过规则审核出 SQL 问题并量化之后，就到了整改阶段。

目前，SQLE 提供了修改建议（知识库）和辅助诊断（SQL 分析）来协助 SQL 问题处理。

• 知识库：每一条规则都会有一篇文档，其中包含了规则涉及的背景知识和规则设置的原理和常见解决方案。

• SQL 分析：使用者在进行 SQL 优化前，会将 SQL 问题涉及到的数据（表结构、索引使用情况、SQL 执行计划）进行整理，实现辅助诊断。

未来，SQLE 会增加主动优化的功能（SQL 改写、专用大模型能力引入），敬请期待。

5SQL 质量管理具体怎么做？

在日常工作中有具体如何将 SQL 质量管理的理念落地呢？让我们先回顾一下软件生命周期。

抛出一些具体差异，每家公司的软件开发流程大体上都如图所示，分为开发、测试、上线、运维等阶段。

站在 SQL 的角度，不同阶段的工作：

• 设计与实现阶段：开发人员需要完成表结构和业务逻辑 SQL 的设计；

• 测试阶段：测试人员验证 SQL 的正确性；

• 部署与发布阶段：运维人员要对库表结构和数据的初始化；

• 生产与运维阶段：运维人员要对环境中的 SQL 进行监控，遇到问题、诊断问题、解决问题。

通过对各阶段 SQL 流转中各岗位工作内容的分析可知，SQL 问题越早解决成本越低！

我们都希望将问题消灭在萌芽中，但我们也无法保证在不同阶段都没有发生的可能性。所以，需要在不同阶段都准备对应的审核手段。

• 
  

  设计与实现阶段

• • 在开发阶段完成自助审核，尽早发现问题。在本阶段我们前面说过，开发阶段主要任务是完成业务功能的开发，能进行 SQL 审核的是非常优秀的开发人员。在尽量低成本且不改变开发习惯的同时完成完成自助审核为主要需求。

  • SQLE 为开发人员提供了常用的 IDE 插件、SQL 客户端和集成 CI/CD 代码扫描等手段，协助开发人员方便简介地完成自助审核。

• 测试阶段

• • 测试人员在该阶段已经知道业务运行的具体 SQL，库表结构，可以更直观的进行审核。还可以审核通过网络层抓包或者云平台提供的审计功能来抓取到具体数据。此阶段进行审核相较其他阶段有一定的优势。

• 部署与发布阶段

• • 该阶段是 SQL 流入生产的一个过程，要实现审核卡点，对上线流程的控制。很多公司有非常规范专业的 SQL 上线流程，由开发和 DBA 来完成流程中的不同任务。

• 生产与运维阶段

• • 主要是 SQL 上线后的监督工作，如图所示：采集慢日志、TopSQL。及时发现生产环境中的问题。

企业如何做好 SQL 质量管理？

相信大家认真阅读本文，结合自身企业的软件开发流程现状，会对这个问题有一个自己的答案。

最后，我们以 SQLE 为例总结如下。在软件生命周期中以 SQL 流转的角度，在四个不同的阶段通过建立规范、上线前控制、标准发布、前控后督，完成闭环渐进式的 SQL 质量提升。

欢迎大家来体验 SQLE 社区版 :)

• ✨ Github：https://github.com/actiontech/sqle

• 文档：https://actiontech.github.io/sqle-docs/

• 官网：https://opensource.actionsky.com/sqle/

Github: https://github.com/actiontech/sqle