仅仅分析“慢SQL”可能也不大够用 ， 因为有很多问题并不是“慢SQL”引发的，一条平时执行时间10毫秒的SQL ， 突变为50毫秒也可能引发一场系统大灾难 。而把“慢SQL”的门槛设定在50毫秒肯定是不合理的 。
还是那句话，Oracle在Top SQL可观测性方面做得很好，而国产数据库在这方面还差强人意 。很多数据库仅仅提供最近执行的SQL的采集接口（条数可以设定，不过设多大才够用呢？），有些数据库虽然在内存中保存着cursor的所有SQL语句，但是无法采集到的SQL的执行计划，而要自动做explAIn又因为参数或者绑定变量的问题而往往无法完成 。无法自动采集到这些信息，就无法发现SQL存在的问题 ， 做自愈也就无从谈起了 。
本来今天还想多写一点，不过现在已经九点了 ， 暂时先写到这里，明天再继续聊吧 。
【数据库的数字化运维能力，你了解了吗？】
推荐阅读
- Docker的各种有用命令
- GreatSQL一个关于主从复制的限制描述与规避
- 如何用Java实现B+树和跳表的高效存储？
- 10分钟搞懂K8S的亲和与反亲和调度
- 网络架构搜索的概念、原理和应用
- 从测度传输的角度来理解和利用神经网络的重要性
- 全卷积网络中FCN与U-net的区别
- 重参数化技术的原理和应用
- 可以接受任意尺寸图像的全卷积神经网络
- Tomcat目录结构详解：从新手到专家的指南