MySQL的存储引擎决定了数据表的存储方式、查询性能以及支持的功能特性，InnoDB和MyISAM是两种使用最广泛的存储引擎，两者的设计目标和应用场景有明显差异。
核心特性对比
下面从多个关键维度对InnoDB和MyISAM进行对比，方便快速了解两者的差异：
| 对比维度 | InnoDB | MyISAM |
|---|---|---|
| 事务支持 | 支持ACID事务，支持提交、回滚、崩溃恢复 | 不支持事务 |
| 锁机制 | 支持行级锁，也支持表级锁 | 仅支持表级锁 |
| 外键支持 | 支持外键约束 | 不支持外键 |
| 全文索引 | MySQL 5.6及以上版本支持 | 原生支持全文索引 |
| 索引结构 | 聚簇索引，主键索引叶子节点存储完整行数据 | 非聚簇索引，索引叶子节点存储行数据的物理地址 |
| count查询性能 | 全表count需要扫描所有行 | 会单独存储表的总行数，count(*)性能更高 |
| 崩溃恢复能力 | 支持崩溃后自动恢复，数据安全性高 | 崩溃后可能出现数据损坏，需要手动修复 |
事务与锁机制差异
InnoDB最大的特性是支持事务，适合需要数据一致性的业务场景。比如电商的订单支付流程，需要同时更新订单状态、扣减库存、增加用户积分，这些操作要么全部成功要么全部失败，使用InnoDB的事务可以保证数据不会出错。
同时InnoDB的行级锁在高并发写入场景下优势明显，多个事务可以同时操作同一张表的不同行，不会互相阻塞。而MyISAM的表级锁在写入时会锁住整张表，此时其他读写操作都会被阻塞，高并发写入场景下性能会明显下降。
下面是开启InnoDB事务的示例代码：
-- 开启事务 START TRANSACTION; -- 执行一系列操作 UPDATE orders SET status = 2 WHERE order_id = 1001; UPDATE product SET stock = stock - 1 WHERE product_id = 50; -- 提交事务 COMMIT; -- 如果出现异常可以回滚 -- ROLLBACK;
索引结构差异
InnoDB采用聚簇索引结构，主键索引的叶子节点直接存储整行数据，二级索引的叶子节点存储主键值，通过二级索引查询时需要先找到主键，再回表查询完整数据。如果表没有定义主键，InnoDB会选择一个唯一非空索引作为主键，如果没有这样的索引，会隐式生成一个6字节的row_id作为主键。
MyISAM的索引都是非聚簇索引，不管是主键索引还是二级索引，叶子节点都存储的是行数据的物理地址，通过索引查询时可以直接定位到数据的存储位置，不需要回表。但也因为这样，MyISAM的主键索引和二级索引没有本质区别，只是主键索引要求唯一非空。
适用场景选择
适合选择InnoDB的场景
- 需要事务支持的业务，比如金融、电商、订单类系统
- 高并发读写场景，需要行级锁提升并发性能
- 需要外键约束保证数据关联完整性
- 对数据安全性要求高，需要崩溃后自动恢复
适合选择MyISAM的场景
- 以读为主，几乎没有写入操作的场景，比如日志表、字典表
- 需要频繁执行count(*)查询获取表总行数
- 不需要事务和外键，追求简单的存储结构
- 老项目历史遗留的表，没有迁移成本的情况下可以继续使用
存储引擎切换方法
如果已经创建了表，需要修改存储引擎可以使用ALTER TABLE语句，示例代码如下：
-- 将表从MyISAM改为InnoDB ALTER TABLE test_table ENGINE = InnoDB; -- 查看表的存储引擎 SHOW TABLE STATUS LIKE 'test_table';
需要注意的是，切换存储引擎可能需要较长时间，尤其是大表切换时，建议在业务低峰期操作，并且提前备份数据。
总结
InnoDB和MyISAM的核心差异来自设计目标的区别，InnoDB侧重数据安全和并发性能，适合大多数业务场景，也是MySQL 5.5之后的默认存储引擎。MyISAM侧重简单的读场景和count查询性能，适合特定的只读类业务。开发者在选择时需要根据业务的实际需求判断，优先选择InnoDB可以避免多数潜在问题。