标签频道
死锁
该标签下的文章、提问与讨论帖。
«结论先行：MySQL 返回的 "1213 (ER_LOCK_DEADLOCK)" 和 "1205 (ER_LOCK_WAIT_TIMEOUT)" 在 InnoDB 里是两个完全不同的失败路径——前者是「检测器选中了你、立即回滚、锁当场释放
背景 我负责一条实时指标落库管道：Kafka 3.5（KRaft，3 broker，topic "metrics-write"，96 分区），消费组 "metrics-writer"，下游 MySQL 8.0.36（16C64G 单主，In
«结论先行：批处理把在线业务拖慢，90% 不是「SQL 写错了」，而是「上线前没人回答三个问题」——它最该跑多快（吞吐预算）、它和在线共享哪些资源（影响面）、它挂了/没跑完怎么办（失败处置）。我 15 年做技术产品，见过 4 起「批处理撞在
«结论先行："SELECT ... FOR UPDATE SKIP LOCKED" 只解决「批处理 worker 之间不撞车」，它完全不知道「在线业务也在写同一批行」——它跳过的是「别人正在锁的行」，而在线事务提交后释放的行，立刻成为批处理
«结论先行："innodb_deadlock_detect" 默认是 ON，它让 InnoDB 在每次锁等待时都主动去「找环」，代价是检测本身的 CPU；在高并发、锁等待者多的场景里，这个「找环」会反过来成为最大的 CPU 消耗者。此时把检
«结论先行：MySQL 默认 REPEATABLE READ（RR）不是"更安全的隔离级别"，而是"更贵的隔离级别"。gap lock、next-key lock 在 RR 下是常态，在 READ COMMITTED（RC）下则大幅收缩。我
【背景】 我负责一条实时指标落库链路：Kafka 消费端把聚合好的指标攒批后写入 MySQL 8.0.36（单主库，12C48G，InnoDB，redo 刷盘 innodb_flush_log_at_trx_commit=1，sync_bi
背景：MySQL 8.0.36 / InnoDB，隔离级别 REPEATABLE READ。用户地址表 user_address，PK=id (bigint auto)，二级索引 idx_user (user_id bigint, addr
«结论先行：在 InnoDB 里，往带唯一索引的表并发 INSERT，最常见的死锁根因不是「写写竞争」，而是 Duplicate Key 检查触发的 S 锁 + 间隙锁，叠加自增主键的插入顺序不一致，形成 AB-BA 环路。这个坑我踩了两次
文
标题
摘要