这是一个创建于 2182 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司应用最近频繁出现慢 SQL 问题，数据库 CPU 跑满 100%那种。由于团队小，很多质量审核方面不完善。一般接口研发接口开发后简单测试都是直接上线，现在线上的 SQL 基本都没经过审核，很多 SQL 都存在未命中索引的问题。想知道 V 友在开发过程中是怎么解决这个问题的，有没有快速的方法实现这样一种流程：研发测试接口->生成接口 SQL 统计->提交审核->生成审核报告->研发修改 SQL ？
PS: 公司接口都是 NodeJS 开发，egg 框架
 |
1
thisisgpy 2018-11-25 00:29:10 +08:00
小团队就不要搞这么复杂了，懂 SQL 的相互 review。
|
 |
2
codelover2016 2018-11-25 00:47:09 +08:00
小团队上监控吧,别搞这种审核的东西...
|
 |
3
jadec0der 2018-11-25 00:47:12 +08:00 via Android
打开 MySQL 的慢查询日志，DBA 或者 SRE 监控慢查询，发现就通知开发改
|
 |
4
glacer OP @codelover2016 @jadec0der 现在就是用监控就去发现，但一些"坏"SQL 在业务低谷并不表现出慢查询的特征，只有在高峰期才会爆发，而一旦爆发就是一次线上故障...所以希望能在上线前就能除掉隐患。
|
 |
5
AltairT 2018-11-25 01:00:38 +08:00
我能说我在的公司最近上了套路云的 RDS，几个人在一起优化慢查询吗？之前也有保存慢查询，但是不统计出来是不知道竟然有几十秒，上百秒的慢查询。团队小，能做的只是加索引，通过执行计划来调整，尽量走索引，有需要配合业务代码的修改。
|
|
6
glacer OP @AltairT 我们也是套路云，一般慢查询能在慢查询日志里查出来优化掉，但有些查询是在一定并发下才会慢，这种就比较头疼，只有在业务异常的时候才会被发现，比较被动。
|
|
7
jadec0der 2018-11-25 01:03:24 +08:00 via Android
@glacer 人工审核 or 压测，有专职 DBA 的话 review 所有 SQL 工作量并不大
|
|
8
AltairT 2018-11-25 01:07:05 +08:00 via iPhone
@glacer 楼上说得对，除非有专职 dba，否则没办法。我们公司一开始也想找个专职 dba，但是奈何庙小钱少，只能一起讨论改改了
|
 |
9
1194129822 2018-11-25 01:43:31 +08:00 via Android
很可能不是 sql 导致的，而且事务导致的，我这边公司也有几十人的技术团队了，一个老项目开了全局事务，造成即使使用 id 查询更新，在并发大的时候都可能搞垮数据库，主要去不掉，没人敢动
|
 |
10
zhengxiaowai 2018-11-25 10:08:20 +08:00
slow query 监控报警，设置查询超时，上线压测。
|
 |
12
jss 2018-11-26 08:30:54 +08:00 via iPhone
数据库设计很重要，不要让小白去做！
|
Select Language