生产案例
随着数据量的增加，数据库cpu占用爆炸，直接100%导致服务崩溃。
原因居然是一个简单的 update 语句。
简单流程如下：
- 定位问题库 > 读库 or 写库
- 查看连接数。cpu利用率到达100%，首先怀疑，是不是业务高峰活跃连接陡增，而数据库预留的资源不足造成的结果。我们需要查看下，问题发生时，活跃的连接数是否比平时多很多。
- 排除连接数激增与读写库挂掉的可能。所以只能是慢sql占用资源
- 定位是否频繁读写造成
select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;
有几张分区表被疯狂读
https://www.jb51.net/article/204841.htm
保姆级教程，如何定位问题sql
7. 慢sql是一句update
update table set xxx = yyy where id = xxx
update table set xxx = yyy where id = xxx and 分区1=xxx and 分区2 = xxx
- 看效果
before
after
监控
ps
想知道分表分区怎么做的出门左转
https://blog.csdn.net/weixin_45893488/article/details/104844933
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
