生产案例
随着数据量的增加，数据库cpu占用爆炸，直接100%导致服务崩溃。
原因居然是一个简单的 update 语句。

赶紧定位问题
简单流程如下：

1. 定位问题库 > 读库 or 写库
2. 查看连接数。CPU利用率到达100%，首先怀疑，是不是业务高峰活跃连接陡增，而数据库预留的资源不足造成的结果。我们需要查看下，问题发生时，活跃的连接数是否比平时多很多。
3. 排除连接数激增与读写库挂掉的可能。所以只能是慢sql占用资源
4. 定位是否频繁读写造成

select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

有几张分区表被疯狂读

6. 定位慢sql
https://www.jb51.net/article/204841.htm
保姆级教程，如何定位问题SQL
7. 慢sql是一句update

update table set xxx = yyy where id = xxx

9. 查看这句sql的执行计划
   

10. 原来这个语句在疯狂扫描全表表，那就是分表分区没有命中，他在做全表扫描

11. 修改sql 用分区键直接指定要update 的表

update table set xxx = yyy where id = xxx and 分区1=xxx and 分区2 = xxx

12. 看效果
    before
    
    after
    
    监控
    
    ps
    想知道分表分区怎么做的出门左转
    https://blog.csdn.net/weixin_45893488/article/details/104844933