慢查询日志没看吗
经验告诉我应该就是周四前面一天某行代码改动所致,于是我把周四前两天提交的所有代码查了一遍,同时还把页面测了一遍,没发现问题……
最后迫不得已,自己整了套工具,将所有数据库查询写入日志,然后用工具查询挂的瞬间没有数据库返回的日志,终于找到了bug……有一个查询在没有数据的情况下居然绕开了我们的数据库安全查询检查,返回了几十万条数据……
Bug本身是个小bug,结果却搞出来了一套数据build工具,以及一套内存监测工具,同时还找出了系统内在潜在的安全隐患,还让整个网站高性能损耗的地方得以被高效优化。
这个,虽然定位问题的过程可能没有直击本质走了点弯路,但结果是不错的。
以前,生产环境出现bug会觉得很遗憾,甚至有点责怪自己或他人;但是现在觉得,每一次bug都是改善系统或优化规范、流程的契机。看开了,团队和系统也变得更好。
这种bug最容易被那些喜欢搞数据库安全研究的帽子客抓住,,查询语句类容易被穷举
辛苦了,码农太不容易了,查Bug更是可以让人疯掉…祝后边一切顺顺当当!
如果使用阿里云,可以考虑使用polardb配套的数据库性能指标监控,阿里云ARMS定位应用问题时按需启用。
为什么不先回滚?
注入?
现在有app了么
请问理杏仁的自由现金流和市值这两个有扣掉少数股东所有的那部分吗?
坏事变好事
现在AI是否可以直接用来查bug?
不容易