文章目录
-
-
- [为什么 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
中出现的字段。 - 具有高选择性(字段值分布均匀,重复值少)的字段。
- 高频查询的字段,如
- 不适合:
- 低选择性字段(如性别、布尔值等)。
- 经常更新的字段,索引维护开销较大。
- 很少出现在查询条件中的字段。