myd是myisam表的数据文件，存储按插入顺序追加的原始字节流，大小基本等于真实数据体积；删之则查无数据但表结构仍存，须与.myi、.frm配套使用，不支持事务和跨实例迁移。
MYD 文件是 MyISAM 表的实际数据载体
它就是表里每一行记录的原始字节流，按插入顺序追加存储，不带任何事务或行锁机制。文件名和表名一致，后缀 .MYD（MYData）。你用 ls -lh 看到的大小，基本等于真实数据体积（压缩表除外）。
常见错误现象：
- 直接删掉 .MYD 文件，SELECT * 就返回空结果，但 SHOW CREATE TABLE 仍能查出表结构——因为 .frm 还在；
- 把 .MYD 复制到另一台 MySQL 实例同目录下，重启服务后表不可用，甚至报错 Table 'xxx' doesn't exist——MyISAM 不支持跨实例热迁移，没配套的 .frm 和 .MYI，光有数据文件毫无意义。
使用场景有限：只适合读多写少、无事务需求的场景，比如日志归档表、报表缓存表。一旦业务需要 UPDATE 频繁或要求崩溃后数据一致，.MYD 的纯堆式存储就扛不住了。
MYI 文件存的是 B+Tree 索引结构，不是数据地址映射表
.MYI（MYIndex）里保存的是完整的索引树节点，包括主键和所有二级索引。每个索引项最终指向 .MYD 中某条记录的**物理偏移量**（不是行号，也不是指针），这点和 InnoDB 的聚簇索引完全不同。
容易踩的坑：
- 给低选择性字段（如性别、状态码）建索引，.MYI 文件会异常膨胀，因为 B+Tree 每个叶子节点都要存一遍重复值的偏移；
- REPAIR TABLE 时如果 .MYI 损坏而 .MYD 完好，有可能重建索引；但如果 .MYD 损坏，.MYI 再完整也恢复不出数据；
- OPTIMIZE TABLE 对 MyISAM 来说本质是“重建 .MYD + .MYI”，能消除碎片，但期间表被锁死，线上慎用。
MYD 和 MYI 必须成对存在，且不能脱离 frm 单独生效
三者缺一不可：.frm 定义列类型、长度、字符集；.MYD 存原始数据；.MYI 提供查找路径。哪怕只少一个文件，MySQL 启动时就会跳过该表，或者在 SHOW TABLES 中不显示。
参数差异注意点：
- MyISAM 支持把 .MYD 和 .MYI 分开存到不同磁盘路径（用 DATA DIRECTORY/INDEX DIRECTORY），但 MySQL 5.6+ 才支持，且路径必须是绝对路径、MySQL 进程有读写权限；
- myisampack 压缩后的表，.MYD 变成 .MYD + .MRG，.MYI 依然存在，但不能再写入；
- MySQL 8.0 默认禁用 MyISAM，skip-grant-tables 或旧备份还原时才可能意外激活，上线前务必确认 show engines; 中 MyISAM 的 SUPPORT 字段不是 DISABLED。
别直接操作 MYD/MYI 文件，除非你清楚后果
它们不是文本文件，也不是标准二进制格式，没有公开文档定义页结构。试图用 hexdump、dd 或第三方工具硬解析，成功率极低——MyISAM 没有 checksum 校验，损坏后连“哪里坏了”都难定位。
真正要恢复数据，优先走逻辑备份：
- 有 mysqldump 输出，就用 mysql ；<br>
- 没备份但 <code>.MYD 和 .MYI 都完好，停库后复制整套文件再启动；
- .MYD 被截断或部分覆盖，myisamchk --safe-recover 是最后一搏，但它可能丢数据，且无法保证顺序一致性。
最常被忽略的一点：MyISAM 表在 INSERT DELAYED 或崩溃后，.MYD 末尾可能残留未刷盘的脏数据块，此时 .MYI 的索引项已更新，但 .MYD 数据没落盘——这种不一致不会报错，只会让查询结果“偶尔少几条”。
