并发控制由锁机制、MVCC和日志系统协同实现：锁机制通过S锁/X锁及行级粒度保障读写互斥；MVCC利用版本链与Read View实现无锁快照读；日志系统依靠undo log支持回滚与多版本，redo log确保崩溃恢复与持久性。
并发控制是 MySQL 保证多事务同时操作数据时不产生冲突、不破坏一致性的核心机制。它不是靠单一技术实现的，而是由锁机制、MVCC（多版本并发控制）和日志系统三者协同完成的。
锁机制：读写互斥的底层保障
MySQL 用两种基础锁协调并发访问：
-
共享锁（S 锁 / 读锁）：多个事务可同时持有，用于只读操作（如普通 SELECT）。它们彼此不阻塞，但会阻塞写锁。
-
排他锁（X 锁 / 写锁）：仅允许一个事务持有，用于 UPDATE、DELETE、INSERT 或加锁查询（如 SELECT … FOR UPDATE）。它会阻塞其他所有读锁和写锁。
锁的粒度分三层：表级锁（如 DDL 期间）、页级锁（InnoDB 索引页内）、行级锁（最常用，默认基于主键或唯一索引）。InnoDB 默认在符合条件时自动使用行锁，大幅减少锁争用。
MVCC：让读操作不加锁也能保持隔离
MVCC 是 InnoDB 在 READ COMMITTED 和 REPEATABLE READ 隔离级别下提升并发的关键。它不依赖锁来解决“读-写冲突”，而是通过保存数据的历史版本实现：
- 每行记录隐含两个系统字段：DB_TRX_ID（最后修改该行的事务 ID）和 DB_ROLL_PTR（指向 undo 日志中前一版本的指针）。
- 事务启动时生成一个Read View，包含当前活跃事务 ID 列表和最小/最大事务 ID 等信息。
- 查询时，InnoDB 沿着版本链逐个比对，只返回对当前事务可见的版本（例如：未被删除、创建事务已提交、修改事务不在活跃列表中等）。
这就解释了为什么在可重复读下，同一事务中多次 SE
LECT 同一行结果不变——它看到的是事务开始那一刻的快照，而非最新值。
日志系统：确保原子性与持久性的支撑
锁和 MVCC 解决的是“怎么读、怎么写不冲突”，而日志系统保障“写到底成没成、出错能不能回”：
-
Undo Log：记录事务修改前的数据版本，支撑 MVCC 的历史读取，也用于事务回滚。
-
Redo Log：记录物理页的变更（如“第 X 页偏移 Y 处写入 Z 字节”），确保崩溃后能恢复已提交事务的修改，实现持久性（DURABLE）。
二者配合，使事务既能安全地并发执行，又能在异常时准确还原状态。
不同操作对应哪种并发行为
理解实际场景有助于掌握原理：
-
普通 SELECT → 快照读，走 MVCC，不加锁（除非隔离级别为 SERIALIZABLE）。
-
SELECT … FOR UPDATE / LOCK IN SHARE MODE → 当前读，加行级 X 锁或 S 锁，阻塞其他写或读。
-
UPDATE / DELETE / INSERT → 先当前读（加锁定位行），再修改并写入 undo + redo。
-
ALTER TABLE（8.0+ Instant DDL） → 表元数据锁极短，不锁数据行；非 Instant 操作仍需短暂表级锁。
