mysql没有mvcc之前遇到了什么问题

MySQL 的 MVCC（Multi-Version Concurrency Control，多版本并发控制） 是 InnoDB 存储引擎实现高并发事务的核心机制之一。它通过为每行数据维护多个版本，避免读写冲突，实现“读不阻塞写，写不阻塞读”，从而提高数据库的并发性能。

在 MySQL 5.1 之前，早期版本的 InnoDB 存储引擎功能较弱，缺乏行级锁外的并发控制优化，表压缩和分区支持不完善。MyISAM 是默认引擎，但不支持事务和崩溃恢复，容易导致数据损坏。

InnoDB 并发控制主要依赖锁机制，这导致了一系列显著的问题，具体表现如下：

✅ 1. 读写互相阻塞，并发性能差

• 没有快照读（Snapshot Read），所有一致性读都必须加 共享锁（S锁）。

• 写操作需要 排他锁（X锁），与读锁互斥。

• 结果是读阻塞写、写阻塞读，高并发下性能急剧下降

✅ 2. 默认存储引擎 MyISAM 不支持行锁

• MySQL 5.1 之前默认使用 MyISAM 存储引擎。

• MyISAM 只支持 表级锁，即：

  • 写操作（INSERT/UPDATE/DELETE）会锁住整张表。

  • 读操作（SELECT）也会阻塞写操作，反之亦然。

• 并发读写场景下性能极差，不适合高并发 OLTP 系统

✅ 3. 无事务隔离级别支持，数据一致性问题严重

• MyISAM 不支持事务，无法解决以下经典并发问题

 ✅4. 死锁与锁等待频繁

• 仅靠锁机制，多个事务交叉访问资源时极易形成死锁。

• 没有 MVCC 的“读不阻塞写”机制，锁竞争严重，死锁检测和回滚开销大

✅ 5. 长事务阻塞严重

• 由于读也要加锁，长查询（如报表）会长时间锁住表，阻塞所有写操作。

• 无法像 MVCC 那样提供一致性快照读，导致线上业务容易被拖垮

✅ 6. 崩溃恢复能力差

• MyISAM 不支持崩溃恢复，一旦宕机，表容易损坏，数据可能丢失

🔍 总结一句话：

MySQL 5.1 之前没有 MVCC，导致“锁太重、表太粗、事务太弱”，并发性能差、数据一致性差、系统稳定性差，难以支撑现代高并发业务。