标签：PostgreSQL 定位问题 SQL 解决方案 分区 xxx update sql where
生产案例
随着数据量的增加，数据库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;
有几张分区表被疯狂读
6. 定位慢sql
https://www.jb51.net/article/204841.htm
保姆级教程，如何定位问题SQL
7. 慢sql是一句update
update table set xxx = yyy where id = xxx
-
查看这句sql的执行计划
-
原来这个语句在疯狂扫描全表表，那就是分表分区没有命中，他在做全表扫描
-
修改sql 用分区键直接指定要update 的表
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
标签：PostgreSQL,定位问题,SQL,解决方案,分区,xxx,update,sql,where 来源： https://blog.csdn.net/weixin_45893488/article/details/122695409
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。