mysql锁机制依存储引擎而异：innodb默认行级锁（锁索引记录，需走索引，否则可能升级为间隙锁或临键锁），myisam仅支持表级锁；二者均存在锁冲突与死锁风险，需通过索引优化、统一操作顺序、拆分事务等手段规避。
MySQL 的锁机制取决于存储引擎，InnoDB 默认使用行级锁，支持高并发；MyISAM 只支持表级锁，适合读多写少场景。理解锁的类型、触发条件和实际影响，是优化并发性能和避免死锁的关键。
行锁（InnoDB）：精确控制，但有前提
InnoDB 的行锁不是直接锁“行”，而是锁索引记录（包括主键索引和唯一索引）。如果 WHERE 条件未命中索引，或使用了范围查询（如 WHERE age > 25），可能升级为间隙锁（Gap Lock）或临键锁（Next-Key Lock），从而锁定索引区间，甚至阻塞无关行的修改。
- 必须走索引才能生效：无索引字段的 UPDATE/DELETE 会退化为全表扫描+行锁逐个加锁，效果接近表锁
- UPDATE 和 DELETE 自动加写锁（X锁），SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 才显式加锁
- 事务提交或回滚后，行锁自动释放；长事务会持续持有锁，增加冲突概率
表锁（MyISAM 和 InnoDB 的特殊情况）
MyISAM 默认对整张表加锁：一个写操作（INSERT/UPDATE/DELETE）会阻塞所有其他写和读；读操作（SELECT）之间不互斥，但会阻塞写。InnoDB 虽以行锁为主，但在某些场景也会使用表级锁：
- 执行 ALTER TABLE、DROP TABLE 等 DDL 操作时，需获取元数据锁（MDL），本质是表级排他锁
- 显式使用 LOCK TABLES ... WRITE（不推荐，会绕过事务机制）
- 大量更新未索引字段，导致优化器放弃行锁，选择表级锁策略（极少见，通常说明设计问题）
锁冲突与死锁：如何定位和规避
行锁冲突常见于多个事务交叉更新同一组行，例如事务 A 更新 id=1 后想更新 id=2，事务 B 反向操作，就可能形成死锁。InnoDB 会主动检测并回滚其中一个事务（返回 ERROR 1213）。
- 用 SHOW ENGINE INNODB STATUS\G 查看最近死锁详情，重点关注 “LATEST DETECTED DEADLOCK” 部分
- 统一 DML 操作顺序（如按主键升序更新多行），可大幅降低死锁概率
- 避免在事务中执行耗时操作（如调用外部接口、大循环），减少锁持有时间
- 监控 innodb_row_lock_waits 和 innodb_row_lock_time_avg 等状态变量，识别锁争用热点
实践建议：从设计到运维
锁不是越细越好，也不是越少越好——关键在于匹配业务特征。
- 高频更新的表优先用 InnoDB，并确保 WHERE 条件始终走有效索引
- 日志类、统计类只读或追加场景，MyISAM 仍具轻量优势，但需接受写阻塞
- 批量更新尽量拆成小事务（如每次 1000 行），避免单事务锁住过多记录
- 应用层做好异常处理：捕获死锁错误后重试，而非直接报错给用户
