【Mysql面试】MyISAM 与 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 在创建表时，如果没有明确指定主键索引，它会按照以下规则选择用于主键的字段：

1. 第一个非 NULL 且唯一的列：
   InnoDB 会查找表中的列，选择第一个定义了 UNIQUE 约束且所有字段都非 NULL 的列作为主键索引。这是优先级最高的情况。
2. 隐式自增 ID：
   如果表中没有符合条件的列（即没有非 NULL 且唯一的列），InnoDB 会自动创建一个隐式主键列。这是一列 6 字节大小的隐藏列，用作聚簇索引的主键。这种情况下，你在表结构中无法直接看到这个列。

---

索引的优缺点及使用建议

优点：

1. 提升查询效率：索引大幅降低查询所需的磁盘 I/O 操作。
2. 加速排序和分组：索引字段可以帮助快速完成 ORDER BY 和 GROUP BY 操作。
3. 保证数据唯一性：唯一索引可避免重复值插入。

缺点：

1. 占用存储空间：索引需要额外的存储空间，数据量越大，索引开销越大。
2. 降低写入性能：每次插入、删除或更新时，索引都需要动态维护，增加了开销。
3. 过多索引会导致查询优化器选择不当，影响整体性能。

索引使用场景：

• 适合：
  1. 高频查询的字段，如 WHERE、JOIN、ORDER BY 中出现的字段。
  2. 具有高选择性（字段值分布均匀，重复值少）的字段。
• 不适合：
  1. 低选择性字段（如性别、布尔值等）。
  2. 经常更新的字段，索引维护开销较大。
  3. 很少出现在查询条件中的字段。

---

参考资料

• 官方博客：切换到 InnoDB
• 性能测试：InnoDB VS MyISAM