SQL分区表写入性能下降主因是热点分区，即因分区键设计不当导致写入集中于少数分区，引发I/O或CPU负载不均；常见诱因包括自增ID哈希、时间范围分区集中当月写入、地区列表分区分布倾斜；可通过元数据查询与慢日志定位，并采用二级分区、组合键、预分配或写入扰动等策略缓解。

SQL分区表写入性能下降，往往不是分区本身的问题，而是分区设计与业务写入模式不匹配导致的“热点分区”现象。简单说，就是大量写入请求持续涌向同一个分区，造成该分区所在数据文件或存储节点负载过高，而其他分区空闲，整体吞吐上不去。

什么是热点分区

热点分区指在哈希、范围或列表分区中，因分区键选择不当或数据分布严重倾斜，导致写入操作长期集中在少数几个（甚至一个）分区上。典型表现包括：

• 单个分区的写入延迟明显高于其他分区
• 对应分区所在的磁盘I/O或CPU使用率持续飙高
• INSERT/UPDATE语句平均耗时上升，但执行计划显示只涉及单一分区
• 分区行数增长极不均衡（如某分区占全表80%数据）

常见引发热点的分区键设计

以下几种情况容易埋下热点隐患：

• 用自增ID做哈希分区键：虽然哈希可分散，但若ID连续写入+分区数固定（如PARTITIONS 4），新数据会按模运算集中到少数几个分区（尤其当ID为偶数或特定步长时）
• 用创建时间做范围分区，且按月/年切分但业务集中在当月：所有新增订单、日志都写入当前分区，历史分区完全只读，无法分摊压力
• 用用户地区code做列表分区，但大部分用户来自同一省份：比如region_code仅设'BJ'、'SH'、'GD'三个分区，而70%用户ID绑定'GD'，该分区独扛大半写入

如何识别和验证热点分区

不依赖猜测，用数据库原生元数据快速定位：

• MySQL：查INFORMATION_SCHEMA.PARTITIONS，重点关注TABLE_ROWS和DATA_LENGTH字段，排序看是否严重不均
• PostgreSQL：运行SELECT partition_name, pg_total_relation_size(partition_name) FROM pg_partition_tree('your_table') ORDER BY 2 DESC;
• 配合慢日志分析：筛选出耗时高的INSERT语句，结合EXPLAIN PARTITIONS确认是否总落在同一分区

缓解热点的实用策略

无需推翻重来，多数情况可通过调整策略快速见效：

• 范围分区加二级哈希：对时间分区下的子表再按用户ID哈希，例如先按年分区，再在2024分区内按user_id % 8拆成8个子分区
• 改用哈希+时间组合键：如PARTITION BY HASH(YEAR(create_time)*1000 + user_id % 100)，打破时间单调性
• 预分配+滚动分区：对高写入表，提前建好未来3个月的范围分区，并定期DROP过期分区，避免每次INSERT触发分区路由计算开销
• 写入端加随机扰动：在应用层对分区键做轻量变形（如user_id * 131 % 1000），比直接用原始ID更均匀（需确保查询仍能精准定位）