不是所有慢update都是数据倾斜，但where命中千万级行且更新非索引/大字段时极可能由数据倾斜导致；需用explain analyze和pg_stat_progress_update定位，结合索引优化、分区对齐访问模式、游标分批及定期analyze治理。

UPDATE 语句慢到卡住，是不是数据倾斜了？

不是所有慢 UPDATE 都是数据倾斜，但当 WHERE 条件命中大量行（比如千万级）、且更新字段又涉及非索引列或大字段（如 TEXT、JSON）时，极大概率是数据倾斜在作祟——本质是单个事务/分区/节点承担了远超平均的写负载。

• 先用 EXPLAIN ANALYZE UPDATE ... 看执行计划：如果出现全表扫描、Seq Scan、或某一个 Worker 耗时占比 >80%，基本可确认
• 检查 WHERE 条件是否落在高基数低选择性的列上（例如 status = 'active' 占全表 95%）
• PostgreSQL 中查 pg_stat_progress_update 视图，能直接看到当前 UPDATE 卡在哪一行范围

加索引就能解决 UPDATE 倾斜？别急着建

索引对 UPDATE 是把双刃剑：它加速定位，但每次更新还要同步维护索引页，尤其当更新涉及索引列本身时，写放大可能翻倍。

• 只给 WHERE 条件中的过滤列建索引，不要给 SET 的列盲目加索引（除非后续高频查询也依赖它）
• 避免在 UPDATE 频繁的列上建普通 B-tree 索引，考虑 BRIN（适合时间序列或天然有序字段）
• MySQL 中若用 innodb_buffer_pool_size 过小，即使有索引，大量随机页写也会触发频繁刷盘，表现像“假倾斜”

按时间/业务主键分片，但别硬切 ID

直接按 id % N 分区容易导致热点，比如新订单都集中在最新几个分片；真正有效的分区得和访问模式对齐。

• PostgreSQL 推荐用 RANGE 分区按 created_at 或 updated_at 切，配合 UPDATE 的时间局部性
• MySQL 8.0+ 支持 LIST COLUMNS 分区，可用业务状态码（如 order_status）做分区键，把“待处理”这类高频更新状态单独成区
• 切记：分区键必须是 WHERE 条件的一部分，否则优化器可能跳过分区裁剪，照样扫全表

批量 UPDATE 拆成小事务，但别用 LIMIT + OFFSET

LIMIT 1000 OFFSET 0 这种分页式更新在大数据量下会越来越慢，因为每次 OFFSET 都要跳过前面所有行。

• 改用游标式更新：记录上一批最后的 id 或 updated_at，下一批 WHERE id > last_id AND ...
• 每批控制在 1k–5k 行，太小事务开销大，太大锁持有时间长，容易阻塞读
• 在事务里显式加 SELECT ... FOR UPDATE SKIP LOCKED（PostgreSQL / MySQL 8.0+），避免并发 UPDATE 争抢同一行

实际中最容易被忽略的点：UPDATE 倾斜常和统计信息陈旧强相关。哪怕加了索引、分了区，如果 ANALYZE 没跑过，优化器仍可能选错执行路径——别只盯着 SQL 写法，定期刷新统计信息比调优单条语句更治本。