并发控制由锁机制、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 沿着版本链逐个比对，只返回对当前事务可见的版本（例如：未被删除、创建事务已提交、修改事务不在活跃列表中等）。
这就解释了为什么在可重复读下，同一事务中多次 SELECT 同一行结果不变——它看到的是事务开始那一刻的快照，而非最新值。
魔法映像企业网站管理系统
下载
技术上面应用了三层结构，AJAX框架，URL重写等基础的开发。并用了动软的代码生成器及数据访问类，加进了一些自己用到的小功能，算是整理了一些自己的操作类。系统设计上面说不出用什么模式，大体设计是后台分两级分类，设置好一级之后，再设置二级并选择栏目类型，如内容，列表，上传文件，新窗口等。这样就可以生成无限多个二级分类，也就是网站栏目。对于扩展性来说，如果有新的需求可以直接加一个栏目类型并新加功能操作
日志系统：确保原子性与持久性的支撑
锁和 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 操作仍需短暂表级锁。
