INSERT会卡住其他写入，因自增主键高并发插入引发索引页级锁争抢，非递增主键更会加剧页分裂与刷脏；RANGE分区和物理拆表可缓解，但需规避长事务与不当路由。
为什么 INSERT 会卡住其他写入？锁不是只锁行吗
MySQL 的 InnoDB 在普通主键 INSERT 时确实默认走行锁，但高并发下频繁向同一索引页末尾追加数据（比如自增主键），会导致“隐式锁升级”：多个事务争抢同一个索引页的 LOCK_X 意向排他锁，实际表现为写入排队。尤其当表没主键或主键非递增（如 UUID）时，随机插入还会引发大量页分裂和缓冲池刷脏，进一步放大锁等待。
实操建议：
- 确认是否真在用自增主键——检查
SHOW CREATE TABLE中主键定义，避免误用VARCHAR或UUID()做主键 - 观察
SHOW ENGINE INNODB STATUS输出里的TRANSACTIONS部分，重点看lock struct(s)数量和wait started时间 - 临时压测时可用
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'快速定位阻塞链
分区表能缓解写入锁吗？什么分区策略真正有用
对写入锁压力，RANGE 分区（按时间/ID 切分）比 HASH 或 LIST 更有效——因为新数据基本只落在最新分区，其他分区的索引页几乎不参与竞争。但注意：MySQL 5.7+ 才支持 ALGORITHM=INPLACE 在线添加分区；8.0 起取消了对非整型列的 RANGE 分区限制，但分区键仍必须是主键/唯一键的子集。
实操建议：
- 按天/月分区时，用
TO_DAYS(created_at)或YEAR(created_at)*100 + MONTH(created_at)，避免用函数导致无法使用索引 - 提前创建未来 3–6 个空分区（用
ALTER TABLE ... REORGANIZE PARTITION），防止插入时触发自动分裂锁表 - 禁用
innodb_file_per_table=OFF，否则所有分区共用一个ibdata1，I/O 和锁依然串行
拆成多张表（shard）比分区更简单？关键在路由逻辑
物理拆表（如 order_202401、order_202402）绕过了 MySQL 内部的分区元数据锁，写入完全隔离。但它把路由责任甩给了应用层——一旦路由出错（比如把 2 月订单写进 order_202401），查询就漏数据，且跨月聚合查必须 UNION ALL，维护成本陡增。
实操建议：
- 优先用时间字段做路由键，别用用户 ID——后者容易导致数据倾斜（比如某大客户单月生成 80% 订单）
- 在 DAO 层封装路由函数，例如 Python 里写
get_order_table_name(order_time)，而非每次 SQL 拼接 - 禁止在事务中跨多张物理表写入，否则无法保证原子性；若必须关联查，用中间表或异步同步到宽表
INSERT ... ON DUPLICATE KEY UPDATE 是锁热点的隐形推手
这个语句表面是“存在就更新”，实际执行分三步：先 SELECT 查唯一索引 → 加 INSERT_INTENTION 锁 → 再决定 INSERT 还是 UPDATE。在高并发下，多个事务同时查同一唯一键（比如用户邮箱），会在该索引记录上形成锁队列，哪怕最终都走 UPDATE，也得排队等前面的锁释放。
实操建议：
- 如果业务允许“最终一致”，改用先
INSERT IGNORE，失败再UPDATE，减少锁持有时间 - 唯一约束字段别设太宽——比如邮箱字段用
VARCHAR(255)但实际平均长度 30，索引前缀过长会拖慢查找和加锁速度 - 监控
Handler_read_rnd_next和Innodb_row_lock_waits，这两个指标突增往往意味着ON DUPLICATE KEY正在成为瓶颈
分区和拆表都不是银弹——分区依赖良好的时间/序列规律，拆表则把一致性风险转移到应用。最容易被忽略的是：没关掉 autocommit=OFF 的长事务，会让锁持有时间从毫秒级拉长到秒级，瞬间压垮所有优化手段。
