MySQL按timestamp列分区时primary key重复解决方案

核心约束提示：MySQL分区表存在强制规则：所有主键、唯一键必须包含分区表达式引用的全部字段，因此任何主键调整方案都不能把分区键timestamp排除在主键字段外，否则会直接触发DDL报错。

以下是经过生产验证的可行方案，可根据业务场景选择：

• 方案1：改造为包含分区键的复合主键
  这是改造成本最低、对业务侵入最小的方案，不需要调整现有分区逻辑：

  • 如果业务本身存在全局唯一的请求ID、流水号等字段，直接将原单字段主键PRIMARY KEY (timestamp)修改为PRIMARY KEY (timestamp, biz_unique_id)即可，哪怕timestamp值完全重复，只要业务唯一字段不同，就不会触发主键冲突，查询时带timestamp条件依然可以正常走分区裁剪，性能和原表基本一致。
  • 如果没有现成的业务唯一字段，可以新增一个bigint类型的自增字段suffix_id，将主键设置为PRIMARY KEY (timestamp, suffix_id)，插入时不需要手动传值，数据库自动生成自增后缀，同timestamp值下自增ID天然不重复，完全规避冲突问题。

• 方案2：写入逻辑层做冲突适配
  该方案不需要修改表结构，适合暂时无法做DDL变更的场景：

  • 低并发场景下，如果timestamp是应用侧生成，可以在写入前做简单判断：如果当前生成的毫秒timestamp已经存在对应记录，就阻塞1毫秒后重新生成时间戳重试，设置合理的重试超时时间即可规避绝大多数冲突。
  • 根据业务逻辑选择冲突处理语法：如果业务允许相同timestamp的后到请求直接丢弃，写入时用INSERT IGNORE语法，遇到主键冲突不会抛出异常，直接跳过本次写入；如果业务需要用新数据覆盖同timestamp下的旧记录，就用INSERT ... ON DUPLICATE KEY UPDATE语法，指定冲突后的字段更新规则即可。
    注意：INSERT IGNORE会静默丢弃数据，ON DUPLICATE KEY UPDATE会覆盖旧数据，必须和业务诉求完全匹配才能使用，避免出现数据不符合预期的问题。

• 方案3：升级时间精度从根源降低重复概率
  毫秒级时间戳在单毫秒QPS大于1时就必然出现重复，高并发场景下重复概率并不低，可以通过提升时间精度从根源减少冲突可能：

  • 将timestamp字段的精度从毫秒（3位小数）升级为微秒（6位小数），字段类型修改为timestamp(6)，同步调整分区表达式适配微秒级时间值，时间精度提升1000倍后，绝大多数业务场景下不会再出现时间戳重复问题。
  • 如果是超高峰值写入的场景，还可以在生成时间戳主键时，给同一微秒内的写入请求追加一个自增序列位，组成「微秒时间戳+同微秒自增序号」的有序主键值，从生成逻辑上完全杜绝重复可能。
    注意：该方案需要执行字段修改和分区规则调整的DDL操作，大表场景下建议使用在线DDL工具执行，避免长时间锁表影响线上业务。

内容的提问来源于stack exchange，提问作者SamYan