怎么设置数据库的报警
报警分为几种（结合我各行各业的工作经验）：
1、无报警（这里主要说是数据库已经不行了，但是报警没有提示。因为设置90%报警，且要持续5分钟，现在是80%，持续了几个小时。）
2、用户操作出现问题（同时我们系统也发现问题）和用户同时发现。比如用户点击页面1秒 2秒 3秒 。。。10秒没出，报502 503等50X 等等. 这个时候我们后台也会报警。这种要先于用户不现实。他没操作之前，这个不知道他点下去是不是超时。
3、在用户操作之后，比如报警提示，锁持续1分钟（3分钟、5分钟），估计投诉电话都打过来了。
4、还有一种是监控比较难以察觉的，比如主从数据库同步有延迟，或者异构数据库通过CDC同步有延迟。其实延迟不是说一旦延迟就是问题，但是延迟大了一定是问题。这个尺度不好拿捏。比如延迟10秒，可能没事，但是恰好有个系统居然那一个时刻就不能延迟。
5、关系型数据库到NoSQL或者到消息队列的不一致性（我觉得天生这种就不可能保障一致性，基本无解）
以上个人水平有限列了一些主要的，一定有其他的。我们先讨论这些主要的。
针对问题1：其实数据库的CPU超过50%的使用率，就开始出现有些请求等待了。有一次在一个技术大会上Oracle的RWP给我们演示了一次压力测试。所以这也是我对各种数据库上的要求，不能是常规的报警界限。
针对问题2：这种可能我们不能100%避免，但是能做的是在上线前，SQL审核以及压测。如果我们的主流程或者说高频访问的SQL，都控制在50ms、20ms甚至几毫秒、微秒级别。那么是可以预防的。一切皆有可能。有一次我就是把一个SQL从20分钟优化到了不到2毫秒。（你要问怎么做到的，报名上我的课吧）
针对问题3：设计上避免长事务锁甚至设计不要锁的场景。比如update 业务单一ID，基本不会锁（除非故意不提交），还有拍卖设计成insert出价，而不是update价格。
针对问题4：禁止大事务。任何CDC都怕大事务。别说CDC怕了，就是主从数据库也怕。我经历过多次这样导致数据库主从断了的情况。不怪数据库。话说能不能CDC（数据同步）就不用。
针对问题5：好好设计表，好好写SQL。减少数据库数量和异构数据库以及中间件。（当真正经历过就会发现，单套数据库的开发和运维真的是最幸福的事情了）
总结一下，会发现好好写SQL，解决了以上所有问题。然后你的数据库真的基本就没有报警了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2906417/ ，如需转载，请注明出处，否则将追究法律责任。
