03-17 00:40
慢查询日志没看吗
经验告诉我应该就是周四前面一天某行代码改动所致,于是我把周四前两天提交的所有代码查了一遍,同时还把页面测了一遍,没发现问题……
最后迫不得已,自己整了套工具,将所有数据库查询写入日志,然后用工具查询挂的瞬间没有数据库返回的日志,终于找到了bug……有一个查询在没有数据的情况下居然绕开了我们的数据库安全查询检查,返回了几十万条数据……
Bug本身是个小bug,结果却搞出来了一套数据build工具,以及一套内存监测工具,同时还找出了系统内在潜在的安全隐患,还让整个网站高性能损耗的地方得以被高效优化。
慢查询日志没看吗
“有一个查询在没有数据的情况下居然绕开了我们的数据库安全查询检查,返回了几十万条数据”,莫非是,注入这个sql语句,可以把你们的数据都拿走
没有灰度机制么。。。
这个,虽然定位问题的过程可能没有直击本质走了点弯路,但结果是不错的。
以前,生产环境出现bug会觉得很遗憾,甚至有点责怪自己或他人;但是现在觉得,每一次bug都是改善系统或优化规范、流程的契机。看开了,团队和系统也变得更好。
这个bug作用很大呀
可以把查询超时时间弄短,宁可查不到,也不会卡住。
应该是oom啊,一般看下/var/log下的文件,oom杀死进程的话里面会有记录;而且服务器没有内存监控么,看一下监控图表就能发现内存使用率飙升
有没有一种可能:“理杏仁” 裁员裁到大动脉了,……
bug变ai了
上云吧,对于慢SQL分析而言,是云上DB实例的基础功能,可以很方便地帮你定位问题