MySQL行锁在秒杀中无法通过调参或SQL改写消除，必须用Redis预扣减过滤、分段更新打散压力、MySQL最终校验三重防御。
MySQL 行锁在秒杀场景下无法靠调参或 SQL 改写消除竞争——所有请求命中同一行，InnoDB 就必须串行加 X 锁。真正有效的路径是：用 Redis 预扣减过滤无效请求，再用分段更新打散单行压力，最后保留 MySQL 做最终校验。
为什么 UPDATE goods SET stock = stock - 1 WHERE id = 123 必然排队
这不是索引没建好、也不是事务提交慢，而是聚簇索引决定了这行数据物理位置固定。所有请求都挤在同一个内存页、同一个锁对象（lock struct）上，InnoDB 只能一个一个放行。你看到的“慢”，其实是大量事务在内存里空转等待：CPU 拉满但磁盘 IO 极低；SHOW ENGINE INNODB STATUS 里反复出现 waiting for trx id；information_schema.INNODB_TRX 中大量事务 trx_state = 'LOCK WAIT' 却状态为 RUNNING。
分段更新必须满足的三个硬前提
把单行库存拆成 10 行（如 shard_id 0~9），实测可降锁冲突 80%+，但漏掉任一条件，效果归零甚至更糟：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
WHERE必须同时含product_id和shard_id，且联合主键顺序为(product_id, shard_id)；若只查shard_id或顺序反了（比如建了(shard_id, product_id)），就会全表扫，锁住全部 10 行 -
EXPLAIN中key字段必须显示PRIMARY，rows ≤ 1；若出现range或index，说明没走对索引 - 事务只包这一条
UPDATE+ROW_COUNT()判断；禁止日志、HTTP 调用、SLEEP()，否则锁滞留时间指数增长 - 隔离级别必须设为
READ COMMITTED：它禁用间隙锁，避免因shard_id查询范围扩大而锁住相邻槽位
Redis 预扣减不是可选项，是必须前置的流量闸门
真实压测中，80% 请求是库存已空还狂点——这些请求根本不该碰 MySQL。必须用 Redis 原子操作提前拦截：
- Key 按
goods_id % 10分片，如goods:123:stock:0~goods:123:stock:9，避免单 key 热点 - 扣减用
DECRBY goods:123:stock:0 1，返回值 ≥ 0 才放行；否则直接拒绝，不走 DB - 异步落库节奏要可控：用
Redis Streams或限速消费者（如每秒最多 500 条），防止 DB 写入突增
MySQL 最终一致性校验不能省
Redis 和 MySQL 之间存在网络分区风险，仅靠 Redis 扣减无法保证强一致。每次真实扣减必须走 MySQL 最终校验：
- SQL 示例：
UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1 - 必须检查
ROW_COUNT()是否为 1；若为 0，说明库存不足，需回滚 Redis 扣减（用INCRBY补回） - 这个判断不是兜底，而是防超卖最后一道防线——哪怕 Redis 和 DB 同时出错，只要这句 SQL 成功执行且
ROW_COUNT() == 1，就绝对不超卖
最容易被忽略的是：分段更新后仍用默认的 REPEATABLE READ 隔离级别，或在事务里混入任意非 DB 操作，都会让所有优化失效。锁竞争不是并发问题，是结构性瓶颈，绕不开精准控制和分层防御。
