mysql如何优化电商秒杀场景下的索引热点问题_分散主键插入压力-mysql教程-PHP中文网

本质是索引结构与自增主键导致锁竞争放大；须用(product_id, shard_id)复合主键替代自增id，删除product_id二级索引，使同商品更新分散至多行，冲突下降90%+。

mysql如何优化电商秒杀场景下的索引热点问题_分散主键插入压力

MySQL 在电商秒杀场景下，单商品 ID 更新导致的索引热点问题，本质不是“要不要加索引”，而是“索引结构和主键设计放大了锁竞争”。直接优化 product_id 上的普通索引或联合索引，治标不治本；必须配合主键/聚簇索引层的分散策略。

为什么 `idx_product_id` 会加剧热点？

很多人给 product_stock 表加 KEY idx_product_id (product_id)，以为能加速 WHERE 查询。但问题在于：

InnoDB 的聚簇索引以主键组织物理存储，而默认主键是自增 id —— 所有新插入或更新都挤在 B+ 树最右叶节点，引发页分裂和写入争用
即使查询走 idx_product_id，UPDATE 语句仍需回表定位到聚簇索引行，最终锁住的是同一行（product_id = 1001 对应的那条记录）
更隐蔽的是：二级索引更新本身也要写 redo log 和 buffer pool，并发高时 idx_product_id 的页也成热点（尤其是 product_id 值高度重复时）

改用哈希分片主键替代自增 ID

目标是让同商品的库存操作落到不同物理位置，天然分散锁和 IO 压力。不依赖应用层随机选桶，而是从主键设计上根治：

财经热点新闻爬取与话题归纳系统

抓取主流财经网站实时热点，提供混合评分与专业HTML报告，支持快讯采集和话题归纳。

下载

将主键改为 (product_id, shard_id) 复合主键，其中 shard_id 是 0–9 的整数（对应 10 个逻辑分片）

建表示例：

CREATETABLEproduct_stock_shard (
  product_idBIGINTNOTNULL,
  shard_idTINYINTNOTNULL,
  stockINTNOTNULLDEFAULT0,
  versionINTNOTNULLDEFAULT0,
  PRIMARYKEY(product_id, shard_id)
) ENGINE=InnoDB;

扣减时不再 UPDATE 单行，而是随机选择一个 shard_id 执行：UPDATE product_stock_shard SET stock = stock - 1 WHERE product_id = 1001 AND shard_id = FLOOR(RAND() * 10);
查总库存用 SELECT SUM(stock) FROM product_stock_shard WHERE product_id = 1001; —— 虽然要扫 10 行，但并发压力已从“1 行锁死”变为“10 行轮转”，冲突下降 90%+

禁止在 `product_id` 上建普通二级索引

这是最容易被忽略的坑。一旦存在 KEY idx_product_id (product_id)，InnoDB 会在该索引页上产生额外的锁竞争：

每个 UPDATE 都要先定位二级索引项，再回表 → 二级索引页本身也会被频繁修改
若多个事务同时更新不同 shard_id 但相同 product_id，它们在 idx_product_id 页上可能命中同一索引页（因 product_id 值相同），触发页级锁
实测表明：删掉这个二级索引后，在 8000 QPS 下，SHOW ENGINE INNODB STATUS 中的 waiting for index latch 消失，P99 延迟从 4.2s 降至 120ms

复合主键下如何高效查单个分片？

有人担心 WHERE product_id = ? AND shard_id = ? 无法利用索引 —— 其实完全不必担心，因为 (product_id, shard_id) 就是主键，B+ 树搜索直接 O(log n) 定位：

执行 EXPLAIN SELECT * FROM product_stock_shard WHERE product_id = 1001 AND shard_id = 3;，type 字段必为 const 或 eq_ref
注意：不能只查 WHERE product_id = 1001（会全索引扫描），所有业务代码必须显式传入 shard_id
推荐在 DAO 层封装：根据 product_id hash 后取模生成 shard_id，确保同商品请求始终落在固定分片（避免跨分片读不一致）