线程池相关故障梳理&总结

下面贴一些典型的常见 Case，开发同学基本一看就懂并不神奇。

数据库相关

热更新

在事务里热更新同一条数据容易引发锁等待造成慢 SQL，常见于一些 update count，update quota 类的业务场景。

• 故障案例1：某次压测对 DB 产生瞬时 60w+ QPS 的压力，期间同一条数据（更新 count 字段）在事务里大量热点更新导致了行锁争抢产生慢 SQL。

• 故障案例2：几个大用户高并发操作，其中涉及单条热点数据在事务里的更新，排查发现单次更新耗时高达5-6秒，积压的线程引起 Dubbo 对外服务线程池堆积，最终线程池满导致无法对外服务。

• • 线下模拟测试发现 1200 并发进行热点数据的更新（在特定的数据库版本和配置下），开启事务需要1分钟，不开启事务需要3秒。

大表加字段

DDL 变更有多种方式，最原始的方式会造成锁表问题进而引发大量相关联 SQL 锁等待产生慢 SQL；DDL 变更建议走 Online DDL。历史上出现过的一些锁表的 Case 应该是没有走 Online DDL，也可能当时数据库版本不支持 Online DDL。

• 故障案例：大表添加字段未采用 Online DDL，在最后阶段会对表加 Metadata Lock 原子锁，使得大量相关 SQL 锁等待产生慢 SQL，进而快速打满应用线程池。

索引没走对