根本原因是锁得不准、锁得太久、锁得不稳；WHERE条件未走索引或事务中含RPC、sleep等会导致全表扫描并误加锁，EXPLAIN显示ALL/index需立即优化，避免隐式转换和函数包裹索引字段。
高并发下 MySQL 行锁竞争的根本原因不是“锁太多”，而是“锁得不准、锁得太久、锁得不稳”。只要 WHERE 条件没走索引，或事务里夹着 RPC 调用、循环处理、sleep，再小的更新也会拖垮整个表。
UPDATE/DELETE 没走索引却还在等锁？
这是最隐蔽也最致命的问题：哪怕 UPDATE t SET status = 1 WHERE id = 123 最终一行都没改（id = 123 不存在），只要没索引，InnoDB 就会扫描全表，并对每行加意向锁甚至行锁。你看到的“卡住”，其实是其他事务在排队等这把“本不该存在”的锁。
- 用
EXPLAIN看type字段：要是ALL或index，立刻停手，别上线 - 避免隐式转换：
WHERE user_id = '123'（user_id是整型）会失效索引；改成WHERE user_id = 123 - 函数包裹必失效：
WHERE DATE(create_time) = '2026-05-01'→ 改成WHERE create_time >= '2026-05-01' AND create_time - 联合索引注意最左前缀：如果建了
(status, category)，但查询只用WHERE category = 'A'，照样全表扫
事务里混进了非数据库操作？
一个事务从 BEGIN 到 COMMIT 的每一毫秒，都在持续持有锁。日志打点、发 MQ、调第三方 HTTP 接口、甚至 file_put_contents 写本地文件——这些都不该出现在事务块里。
- 把通知类逻辑移出事务，用异步任务或最终一致性补偿
- 批量更新拆成小批：比如 10 万条记录，用
UPDATE ... WHERE id IN (1,2,...,500)分页提交，每批控制在 100–500 行 - 避免“先
SELECT再UPDATE”：改成SELECT ... FOR UPDATE WHERE id = ?一步到位，且必须带ORDER BY id防死锁 - 长事务监控：查
information_schema.INNODB_TRX，重点关注trx_started和trx_state = 'RUNNING'的记录
为什么 READ COMMITTED 能显著减少锁冲突？
默认的 REPEATABLE READ 在 RR 级别下启用间隙锁（Gap Lock）和临键锁（Next-Key Lock），哪怕你只更新一行，也可能锁住前后几个空隙，导致插入新记录也被阻塞。而 READ COMMITTED 下，InnoDB 只加记录锁（Record Lock），不锁间隙，且语句执行完就释放不匹配的锁。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确认业务是否容忍“不可重复读”：比如订单详情页两次刷新看到不同状态，多数场景可接受
- 修改方式：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED（连接级）或全局配置transaction_isolation = 'READ-COMMITTED' - 配合
binlog_format = ROW可保证主从一致性，无需降级顾虑 - 注意：
SELECT ... FOR UPDATE在 RC 下仍加记录锁，但不会锁 gap，所以 INSERT 不再被意外阻塞
乐观锁不是银弹，但适合哪些场景？
乐观锁本质是把锁冲突从数据库转移到应用层重试，它不减少锁，而是让锁失败更快暴露、更可控。适用于“读多写少 + 更新逻辑简单”的场景，比如状态机流转、库存预扣减、计数器累加。
- 必须有版本字段：
UPDATE order SET status = 2, version = version + 1 WHERE id = 123 AND version = 5，检查ROW_COUNT()是否为 1 - 重试要有上限（如 3 次）和退避（如
usleep(10000)），避免雪崩式重试 - 不要在事务里嵌套乐观更新：否则重试时可能遇到“事务已提交但版本不一致”的脏状态
- 强一致性热点（如用户余额）建议用 Redis + Lua 做原子预扣，MySQL 仅做最终落库，彻底分流
真正难的从来不是加什么锁，而是判断哪一行该被锁、锁多久、谁来承担失败成本。线上跑着的每个 FOR UPDATE，都应该有对应的服务监控指标和降级预案——否则优化再细，也扛不住一个没加索引的 LIKE '%keyword%'。
