文章目录
-
-
- [为什么 MySQL 默认选择 InnoDB，而不是 MyISAM？](#为什么 MySQL 默认选择 InnoDB，而不是 MyISAM？)
- [MyISAM 与 InnoDB 的主要区别](#MyISAM 与 InnoDB 的主要区别)
- [InnoDB 没有主键时如何处理？](#InnoDB 没有主键时如何处理？)
- 索引的优缺点及使用建议
- 参考资料
-
为什么 MySQL 默认选择 InnoDB，而不是 MyISAM？
1. InnoDB 的核心优势：
- 事务支持 ：InnoDB 是事务型存储引擎，支持
ACID（原子性、一致性、隔离性和持久性）事务特性，并提供崩溃恢复机制，这是现代数据库系统的重要特性，而 MyISAM 不支持事务。 - 行级锁：InnoDB 支持行级锁定（Row Locking），在并发写入时性能更优。而 MyISAM 只支持表级锁定，容易造成性能瓶颈。
- 外键支持：InnoDB 支持外键约束，保证了数据库的完整性，而 MyISAM 不支持外键。
- 崩溃恢复 ：InnoDB 通过
Redo Log和Undo Log支持崩溃后自动恢复数据，适合高可靠性要求的场景。MyISAM 在崩溃时需要手动修复数据，且可能造成数据丢失。
2. MyISAM 的劣势与限制：
- 不支持事务和外键：在需要复杂业务逻辑的情况下，MyISAM 的功能不足。
- 并发性能较差：表级锁导致高并发下性能下降。
- 不支持 MVCC：MyISAM 不支持多版本并发控制（Multi-Version Concurrency Control），并发性能远不如 InnoDB。
3. 面向未来的设计： MySQL 从 5.5 版本开始，默认存储引擎改为 InnoDB，因为：
- 现代应用场景需要更高的数据可靠性和一致性。
- 支持事务的存储引擎已成为行业主流。
- 随着硬件性能的提升，InnoDB 在复杂场景下的性能更好。
MyISAM 与 InnoDB 的主要区别
| 特性 | MyISAM | InnoDB |
|---|---|---|
| 事务支持 | 不支持 | 支持 ACID 事务 |
| 锁机制 | 表级锁 | 行级锁（更高并发性能） |
| 外键支持 | 不支持 | 支持 |
| 崩溃恢复 | 不支持自动恢复 | 支持通过日志恢复 |
| 全文索引 | 支持（早期版本更有优势） | 从 MySQL 5.6 开始支持全文索引 |
| 存储限制 | 256TB | 64TB |
| 数据存储方式 | 非聚集索引，索引和数据分离 | 聚集索引，数据和索引存储在一起 |
| 适合场景 | 查询多，写入少，事务要求低 | 高并发读写，事务性需求高，数据一致性要求严格 |
InnoDB 没有主键时如何处理？
InnoDB 在创建表时，如果没有明确指定主键索引，它会按照以下规则选择用于主键的字段：
- 第一个非
NULL且唯一的列：
InnoDB 会查找表中的列，选择第一个定义了UNIQUE约束且所有字段都非NULL的列作为主键索引。这是优先级最高的情况。 - 隐式自增 ID：
如果表中没有符合条件的列（即没有非NULL且唯一的列），InnoDB 会自动创建一个隐式主键列。这是一列 6 字节大小的隐藏列，用作聚簇索引的主键。这种情况下，你在表结构中无法直接看到这个列。
索引的优缺点及使用建议
优点：
- 提升查询效率：索引大幅降低查询所需的磁盘 I/O 操作。
- 加速排序和分组 ：索引字段可以帮助快速完成
ORDER BY和GROUP BY操作。 - 保证数据唯一性：唯一索引可避免重复值插入。
缺点：
- 占用存储空间：索引需要额外的存储空间，数据量越大，索引开销越大。
- 降低写入性能：每次插入、删除或更新时，索引都需要动态维护，增加了开销。
- 过多索引会导致查询优化器选择不当，影响整体性能。
索引使用场景：
- 适合：
- 高频查询的字段，如
WHERE、JOIN、ORDER BY中出现的字段。 - 具有高选择性（字段值分布均匀，重复值少）的字段。
- 高频查询的字段，如
- 不适合：
- 低选择性字段（如性别、布尔值等）。
- 经常更新的字段，索引维护开销较大。
- 很少出现在查询条件中的字段。