各位 V 友，大家是如何审核要发布上线的接口中的 SQL 语句的呢？

[glacer]

公司应用最近频繁出现慢 SQL 问题，数据库 CPU 跑满 100%那种。由于团队小，很多质量审核方面不完善。一般接口研发接口开发后简单测试都是直接上线，现在线上的 SQL 基本都没经过审核，很多 SQL 都存在未命中索引的问题。想知道 V 友在开发过程中是怎么解决这个问题的，有没有快速的方法实现这样一种流程：研发测试接口->生成接口 SQL 统计->提交审核->生成审核报告->研发修改 SQL ？

PS: 公司接口都是 NodeJS 开发，egg 框架

[thisisgpy]

小团队就不要搞这么复杂了，懂 SQL 的相互 review。

[codelover2016]

小团队上监控吧,别搞这种审核的东西...

[jadec0der]

打开 MySQL 的慢查询日志，DBA 或者 SRE 监控慢查询，发现就通知开发改

[glacer]

@codelover2016 @jadec0der 现在就是用监控就去发现，但一些"坏"SQL 在业务低谷并不表现出慢查询的特征，只有在高峰期才会爆发，而一旦爆发就是一次线上故障...所以希望能在上线前就能除掉隐患。

[AltairT]

我能说我在的公司最近上了套路云的 RDS，几个人在一起优化慢查询吗？之前也有保存慢查询，但是不统计出来是不知道竟然有几十秒，上百秒的慢查询。团队小，能做的只是加索引，通过执行计划来调整，尽量走索引，有需要配合业务代码的修改。

[glacer]

@AltairT 我们也是套路云，一般慢查询能在慢查询日志里查出来优化掉，但有些查询是在一定并发下才会慢，这种就比较头疼，只有在业务异常的时候才会被发现，比较被动。

[jadec0der]

@glacer 人工审核 or 压测，有专职 DBA 的话 review 所有 SQL 工作量并不大

[AltairT]

@glacer 楼上说得对，除非有专职 dba，否则没办法。我们公司一开始也想找个专职 dba，但是奈何庙小钱少，只能一起讨论改改了

[1194129822]

很可能不是 sql 导致的，而且事务导致的，我这边公司也有几十人的技术团队了，一个老项目开了全局事务，造成即使使用 id 查询更新，在并发大的时候都可能搞垮数据库，主要去不掉，没人敢动

[zhengxiaowai]

slow query 监控报警，设置查询超时，上线压测。

[LemonCoo1]

@glacer 你们这个应该是并发问题，平时不慢说明数据库压力不大，建议压测看看各系统资源情况，热数据上缓存

[jss]

数据库设计很重要，不要让小白去做！