企业如何做好 SQL 质量管理?
研发人员写 SQL 操作数据库想必一定是一类基础且常见的工作内容。如何避免 “问题” SQL 流转到生产环境,保证数据质量?这值得被研发/DBA/运维所重视。
什么是 SQL 问题?
对于研发人员来说,在日常工作中,大部分都需要使用数据库。项目中的很多业务都需要进行增删改查等常见数据库操作,这些数据库操作对应的 SQL 语句主要都是由开发人员编写的。对于 DBA 来说,作为数据库管理和运维人员,DBA 负责数据库的日常运维工作。当出现问题 SQL 时,DBA 通常首当其冲负责问题诊断。
那么,什么是 SQL 问题或者说问题 SQL 呢?从一个更广泛的定义来看,SQL 问题指影响业务正常运行的各种 SQL 相关问题。比如图上举例的案例,它们都可以被归类为 SQL 问题。爱可生作为一家数据库公司,我们从客户那里获得了大量的反馈,每年都会因为 SQL 问题导致几起高级别的生产事故。类似的 SQL 问题导致业务中断的新闻也时不时会出现。
对研发人员来说,这些 SQL 问题在开发阶段很难被发现,因为研发的首要任务是保证需求实现。此外,按我们对研发人群和客户的调研结果显示,研发人员在新功能开发阶段通常没有时间对 SQL 进行优化,往往只要能完成需求交付就已经很不错了。一方面是项目进度压力大,另一方面研发人员自身水平和经验也有高有低。所以研发人员很难对所有的 SQL 全面进行优化。下面我们举一个真实且典型的案例。
一个典型的 SQL 问题案例
图中有三张表,请注意表的字符集的不同,分别是 UTF8 和 UTF8MB4。
我们将三张表两两进行联合查询时,分为字符集一致和不一致两种情况。
当字符集不一致时,从执行计划中可见进行了全表扫描,表关联字段未命中索引。
当每张表有 80 万条测试数据时,执行时间差异明显,字符集不一致的 SQL 执行时间达到了 0.9 秒。随着数据量的增加,该 SQL 的问题会愈加明显,两表联查时表的字符集不匹配会导致查询效率大幅下降。这就是一个典型的 SQL 问题。
可能你会觉得本案例的 SQL 问题看似不该发生,但我们的团队曾多次在客户的生产环境中遇到过类似的情况。但根据大家所掌握的慢 SQL 优化习惯来看,有些引发问题的因素是反直觉的。就本案例也不一定会立刻将问题定位和排查出来。所以,我们需要一种更高效的方式来帮助研发人员解决这类问题。
全方位提高 SQL 质量
SQLE 是一款全方位的 SQL 质量管理平台,覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升 SQL 上线效率,提高数据质量。
SQLE 于 2021 年 10 月 24 日这个属于开发者的日子正式开源,至今已经两年多。我们保持每个月发布新版本的频率,不断更新和迭代产品功能。
前面的典型 SQL 问题案例,在 SQLE 中如何解决呢?
根据上图可见,SQLE 会在相同的情况下触发审核规则,快速准确的给出审核结果。
在 SQLE 中有非常丰富的 SQL 规则,上面的案例触发了索引失效类规则中的一条。通过制定一套完善的 SQL 规则规范,是做好 SQL 质量管理的第一步。
做好 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 改写、专用大模型能力引入),敬请期待。
SQL 质量管理具体怎么做?
在日常工作中有具体如何将 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/
更多技术文章,请访问:https://opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量管理平台,覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升上线效率,提高数据质量。
SQLE 获取

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
DDD领域驱动设计理论|得物技术
一、前言 领域驱动设计简称“DDD”,一套“知易行难”的方法论。同时我所工作的这些年,尤其在某大厂做初创项目的那段时间,经常会产生各式各样的“思想碰撞”,特别在设计中台基建类领域时,为了保证充足的扩展性和稳定性,都要好好的“碰撞”一下。虽然在设计过程中,每个人的想法不尽相同,但是最终达成一致的那一刻,每个人的技术思想都会得到提升。 对于DDD,我的观点是,它是一套非常优秀的能提升个人认知高度的方法论。注意,我说的是个人认知,不仅是它所带来的业务和团队价值(它所带来的业务和团队价值会在下面讲)。它的战略设计方法论能很好提升技术人员的全局视野,它的战术设计方法论也能强化个人的技术细节把控力和结构性思维。除此之外,好的DDD设计也反映出一个技术人员对于业务的理解力,往往优秀的领域专家也是半个业务专家。 如果你一直困惑于自己究竟该如何提升技术和业务思考能力;如何提升全局视野,提升自己的结构化思维的能力;如何在写了这么多代码,做了这么多需求的情况下,补充系统化的技术理念。如果这些疑惑点你都涉及,那么理解DDD,同时按照DDD的方式去思考和建设,能够为你带来显著的提升。 同时我还要说明下,因为DD...
- 下一篇
探索设计与代码的融合 Design as Code VS Design to Code
前言 随着数字化时代的飞速发展,设计与代码的融合愈发成为数字产品开发的重要趋势。一直以来,传统的设计和开发流程似乎总是难以摆脱沟通障碍、实现上的妥协,以及低下的工作效率。在这样的背景下,如何把设计师的灵感火花快速而精准地转化为用户界面,成了每个团队必须面对的挑战。今天,我们就来聊聊Design-to-Code(D2C,设计到代码)的痛点,并探索一种新兴的趋势——Design-as-Code(DAC,设计即代码),看看它如何为设计和代码的融合开辟新天地。 主流的设计开发流及其问题 在传统应用开发流程中,大前端开发者和 UI/UX 设计师各自承担着关键的角色。大前端开发者负责编写应用程序的代码,而 UI/UX 设计师则致力于创造应用程序的视觉体验和交互流程。虽然这两个角色的专业背景和使用的工具存在显著差异,他们仍在各自独立的轨道上为共同的产品目标努力。 当设计师完成 UI 和 UX 设计后,接下来的重点便是将这些设计转化为实际的用户界面。这一过程中,开发团队需要根据设计稿手动编写代码,这不仅是一项耗时的任务,而且要求开发者能够精确地理解并转化设计意图并确保应用的视觉效果和交互逻辑与设计稿...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启