MySQL的MyISAM存储引擎是早期版本中的默认选型，即便在后续版本被InnoDB取代，它依然凭借结构简单、读取速度快等特性活跃在特定的业务系统中。要真正掌握MyISAM，需要从文件构成、索引机制、锁模型以及运维限制等多个维度去拆解，而不是只停留在“不支持事务”这一句结论上。
文件结构与数据存储原理
MyISAM将每张表拆成三个物理文件，分别是以.frm结尾的表结构文件、以.MYD结尾的数据文件和以.MYI结尾的索引文件。这种分离设计让数据文件和索引文件可以放置在不同的磁盘路径上，在海量只读场景下方便通过符号链接做IO分摊。数据文件中，行记录按照插入顺序紧密排列，没有页分裂和聚簇索引带来的碎片整理负担。
索引文件内部采用B+树结构，但和InnoDB最大的不同在于：MyISAM的索引叶子节点保存的不是完整行数据，而是数据文件中对应行的物理偏移量。也就是说，通过主键或二级索引查到偏移量后，引擎会再去.MYD文件里把那一段字节读出来。这样的设计使得二级索引和主键在存储上完全平等，不需要回表的概念，但也意味着每一次索引访问都至少发生两次文件定位。
由于数据和索引解耦，MyISAM在备份时甚至可以直接拷贝这三个文件实现冷备，不需要复杂的redo和undo日志参与。下面的示例展示了在Linux下查看一张MyISAM表文件占用的常见命令，可以直观看到三种文件的并存关系。
# 查看test库下user表对应的MyISAM文件 ls -lh /var/lib/mysql/test/user.* # 输出示例： # user.frm 9.2K # user.MYD 120M # user.MYI 34M
表级锁机制与并发表现
MyISAM仅支持表级锁，任何对表的写操作都会锁住整张表，阻塞其他会话的读写。这听起来非常低效，但在实际业务中需要分场景看待。对于以SELECT为主的配置表、字典表，写操作极少发生，表锁几乎不会成为瓶颈。而对于INSERT密集且允许并发读的场景，MyISAM提供了“并发插入”特性：当表中间没有空洞时，读锁和写锁可以并行，写入总是追加在文件末尾。
相比之下，InnoDB的行锁虽然精细，却需要索引配合，且在二级索引锁冲突、间隙锁等情况下容易引发死锁与锁升级。MyISAM因为没有事务，也就不存在回滚和锁等待超时，在ETL批量导入、日志归档等“一次写、多次读”的任务里，反而比InnoDB更轻量。我们可以通过SHOW TABLE STATUS观察表的引擎类型与行数估算，辅助判断是否适合保留MyISAM。
下面的SQL演示了如何查看当前表的引擎，以及在MyISAM上执行写操作时通过LOCK TABLES显式加锁，从而避免自动并发插入造成的计数不一致问题。
-- 查看表的存储引擎
SHOW TABLE STATUS LIKE 'log_archive'G
-- 显式锁定表进行安全批量写入
LOCK TABLES log_archive WRITE;
INSERT INTO log_archive (msg) VALUES ('batch job start');
INSERT INTO log_archive (msg) VALUES ('batch job end');
UNLOCK TABLES;
功能限制与运维注意事项
MyISAM不支持事务、外键和崩溃恢复，这是它被逐渐边缘化的根本原因。如果服务器突然断电，MyISAM表很可能处于未刷新状态，重启后需要通过REPAIR TABLE命令重建索引，极端情况下数据文件损坏无法修复。为此，MySQL提供了myisamchk工具，在离线状态下检查和修复表，但这个过程会长时间锁表，不适合高可用系统。
另一个常被忽视的点是MyISAM的全文索引。在MySQL 5.6之前，只有MyISAM原生支持FULLTEXT索引，这让它成为很多轻量搜索功能的首选。虽然现在InnoDB也支持全文索引，但MyISAM在自然语言分词上的历史积累仍有一些老系统依赖。下面的代码展示了在MyISAM表上创建全文索引并进行简单搜索的写法。
-- 创建带全文索引的MyISAM文章表
CREATE TABLE articles (
id INT NOT NULL AUTO_INCREMENT,
title VARCHAR(200),
body TEXT,
PRIMARY KEY (id),
FULLTEXT (title, body)
) ENGINE=MyISAM;
-- 自然语言模式搜索
SELECT id, title FROM articles
WHERE MATCH (title, body) AGAINST ('数据库优化' IN NATURAL LANGUAGE MODE);
在容量规划上，MyISAM单表最大可达256TB（受操作系统文件大小限制），但表级锁和缺乏热备让它在核心交易链路中风险过高。合理的做法是把MyISAM限制在只读报表、历史数据归档、临时计算中间表等“丢数据可重建”的场景，而把用户、订单等强一致需求放在InnoDB。通过混合使用不同引擎，才能在性能与可靠性之间取得平衡。