写入热点分区是指大量写入操作持续集中在某一个或少数几个分区，导致对应数据节点CPU、I/O、锁竞争严重而成为性能瓶颈；常见于按seller_id、tenant_id等业务主键哈希或范围分区时，因某些卖家或租户数据量远超均值所致。
什么是写入热点分区
写入热点分区是指在分区表中，大量写入操作（如INSERT、UPDATE）持续集中在某一个或少数几个分区上，导致该分区所在的数据节点CPU、I/O、锁竞争严重，成为性能瓶颈。常见于按业务主键（如seller_id、tenant_id）哈希或范围分区时，当某些卖家、租户数据量远超均值，其对应分区就会“过载”。
典型成因与识别方法
热点往往不是设计失误，而是业务增长带来的自然结果。关键要能及时发现：
-
数据倾斜明显：用
SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='orders'查各分区行数，若某分区行数是平均值的5倍以上，需警惕 -
慢查询集中在单一分区：结合慢日志与执行计划，看是否频繁出现
Partition: p_seller_88但耗时突增 - 数据库监控报警：如PolarDB-X中某DN节点QPS/IO使用率长期>90%，而其他节点闲置
热点分区拆分的实操路径
拆分不是简单“一分为二”，而是要在保持业务可用前提下，平滑迁移负载。以MySQL和PostgreSQL主流场景为例：
-
哈希分区热点：原为
PARTITION BY HASH(seller_id) PARTITIONS 8，现发现seller_id=88占70%写入。可改用MOD(seller_id * 1000 + RAND() * 100, 64)类扰动函数重分布，再重建表（需停写窗口）；更优方案是升级为二级分区——先按seller_id哈希分大区，再按时间范围子分区，把大卖家的写入打散到多个时间片 -
范围分区热点：如订单表按
YEAR(order_date)分区，但2024年数据暴增且集中在12月。不应直接拆年份，而应细化为YEAR(order_date)*100 + MONTH(order_date)，将p2024拆为p202401~p202412，让12月流量只压在p202412，不拖累全年 -
在线拆分（无锁方案）：对不能停服的系统，可用“影子分区”法——新建临时分区表接收新写入，旧分区只读；同步双写一段时间后切流，最后归档旧分区。PostgreSQL的
ATTACH PARTITION和MySQL 8.0+的REORGANIZE PARTITION都支持此模式
避免二次热点的设计建议
拆完不是终点，后续维护决定能否长效：
- 分区键优先选高基数、低相关性字段，慎用自增ID或强业务ID作唯一拆分依据
- 预设“弹性分区数”，如哈希分区初始设16个，预留扩容至64的能力，避免频繁重建
- 配合应用层做写入路由，例如大卖家订单加随机后缀再哈希，主动打散
- 定期运行分区健康检查脚本，自动告警行数偏差>300%的分区
