分区表不能缓解buf_pool_mutex锁竞争，仅innodb_buffer_pool_instances参数可降低该全局锁争用；分区表真正缓解的是行锁/表锁粒度导致的dml并发瓶颈，前提是分区键包含在主键或唯一索引中，且写入能自然分散到多分区。
分区表本身不能减少 buf_pool_mutex 这类 Buffer Pool 全局锁竞争——这是常见误解。真正能缓解 Buffer Pool 锁争抢的，只有 innodb_buffer_pool_instances 参数调优；而分区表缓解的是另一类锁：行锁/表锁粒度带来的并发瓶颈，尤其是 DML 高频写入同一热点页或索引页时。
分区表对锁竞争的实际作用边界在哪里
MySQL 分区表在 InnoDB 引擎下，每个分区是独立的 .ibd 文件，拥有各自的 B+ 树索引、页缓存和锁管理单元。这意味着：
- 不同分区上的
INSERT/UPDATE/DELETE操作可并行执行，互不阻塞（只要不跨分区） - 同一分区内的行锁仍受标准 InnoDB 行锁机制约束，不会因为分区就“自动变细粒度”
-
DROP PARTITION是元数据操作 + 文件删除，不触发行锁，比DELETE FROM ... WHERE time 快几个数量级，且不产生成千上万的 undo log 和锁等待 - 分区键若未包含在主键/唯一索引中，会导致索引失效，反而引发全分区扫描和更重的锁竞争
必须满足的分区键与索引组合条件
InnoDB 要求：如果表有主键或唯一索引，分区键字段必须全部包含在这些索引中。否则建表会失败，或导致查询无法 prune 分区（即“查所有分区”），锁范围爆炸。
错误示例：CREATE TABLE logs (id BIGINT PRIMARY KEY, ts DATETIME, msg TEXT) PARTITION BY RANGE (YEAR(ts)) → 报错 ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function
正确做法（二选一）：
- 把
ts加入主键：PRIMARY KEY (id, ts) - 改用无主键表（不推荐），或改用
KEY(ts)+PARTITION BY RANGE COLUMNS(ts)
否则即使建表成功，SELECT * FROM logs WHERE ts BETWEEN '2024-01-01' AND '2024-06-01' 也可能扫描全部分区，锁住远超必要的数据页。
分区策略选择直接影响锁分散效果
不是所有分区方式都能缓解锁竞争。关键看写入是否天然分散到不同分区：
-
RANGE 分区（按时间）：适合日志类、订单类场景。新写入集中在最新分区（如
p202606），旧分区只读，锁竞争集中在单一分区 —— 此时没缓解，反而加剧热点 -
LIST/HASH 分区（按业务 ID 或哈希）：如
PARTITION BY HASH(user_id % 8)，能把用户写入打散到 8 个分区，显著降低单一分区的锁排队概率 -
注意：HASH 分区无法
DROP单个分区删旧数据，需配合归档表或TRUNCATE替代
验证是否生效：执行 SHOW PROFILE FOR QUERY N 或观察 INFORMATION_SCHEMA.INNODB_TRX 中事务锁等待的 LOCK_TRX_ID 是否集中于少数分区对应的表空间 ID（SPACE 字段）。
为什么你看到 QPS 上不去，却查不到明显锁等待？
当 Buffer Pool 实例数为 1，且 innodb_buffer_pool_size 设得很大（比如 12G），高并发下大量线程卡在 buf_pool_mutex 等待，但 SHOW ENGINE INNODB STATUS\G 的 TRANSACTIONS 段可能只显示“waiting for lock”，而 SEMAPHORES 段会出现大量 RW-latch created in file buf0buf.cc —— 这才是真瓶颈，不是分区能解决的。
此时该优先检查：
-
SELECT @@innodb_buffer_pool_instances是否为 1 -
SHOW GLOBAL STATUS LIKE 'innodb_buffer_pool_wait_free'值是否持续增长 -
SET GLOBAL innodb_buffer_pool_instances = 8（需配合 chunk_size 计算，避免 OOM）
分区表和 innodb_buffer_pool_instances 解决的是不同层级的并发瓶颈，混用前得先分清当前卡点在哪一层。
