myisam静态表读取速度略快于动态表，全表扫描在机械硬盘上快15–25%、ssd上低于5%，因静态表可直接计算行偏移且无长度标记解析开销；动态表则易碎片化，需optimize table修复。
MyISAM静态表 vs 动态表：读取速度差异明显吗？
差异确实存在，但不是“快几倍”那种量级，而是取决于访问模式。静态表（MyISAM Static）在全表扫描或按主键/索引顺序遍历时，I/O更可预测：每行偏移 = 行号 × 固定长度，MySQL可以直接计算位置，跳过解析行头开销。动态表（MyISAM Dynamic）每行开头要存一个2字节长度标记，读取时必须先读这个标记再跳转，多一次磁盘随机访问或缓存未命中。
实操建议：
- 如果查询以
SELECT * FROM t WHERE id = ?为主，且id是主键（聚簇索引不适用 MyISAM，但主键索引仍能定位行号），静态表优势微弱，实际测不出明显差距 - 如果是
SELECT COUNT(*)或SELECT * FROM t LIMIT 1000这类顺序遍历，静态表在机械硬盘上可能快 15–25%，SSD 上通常低于 5% - 不要为了这点读速牺牲灵活性——只要表里有一个
VARCHAR、TEXT或BLOB字段，MyISAM 就自动切到动态格式，无法强制回退
动态表碎片导致的性能衰减怎么量化？
碎片不是“慢慢变慢”，而是在特定操作后突然恶化。典型场景是频繁 UPDATE 变长字段（比如把 VARCHAR(50) 从 'a' 改成 'new long value'）：原位置放不下，MySQL 把新记录写到文件末尾，旧位置留空，形成“空洞”。后续 SELECT 扫描时仍要跳过这些空洞，逻辑行数不变，物理读放大。
常见错误现象：
-
SHOW TABLE STATUS显示Data_free值持续增长（比如 > 表数据大小的 20%） - 同样
SELECT * FROM t，执行时间从 0.02s 涨到 0.15s，Handler_read_rnd_next状态值飙升 -
OPTIMIZE TABLE t后立刻回落到原始水平，但一两周又复现
这不是配置问题，是存储格式固有限制。MyISAM 不像 InnoDB 那样有页合并机制，只能靠 OPTIMIZE TABLE 重建 .MYD 文件。
静态表的“空间浪费”在什么情况下真成问题？
浪费只发生在 CHAR 类型字段上，且仅当实际内容远短于定义长度时。例如 CHAR(255) 存储平均长度为 12 的用户名，每行浪费约 243 字节。100 万行就是 ~243MB —— 这比多数人预估的要实在。
但注意两个关键点：
-
CHAR末尾空格在检索时被自动截断，SELECT name FROM t返回的值不会带填充空格，应用层无感知 - 如果字段定义为
CHAR(10)且几乎总是存满（如国家代码、状态码），那根本不算浪费，反而比VARCHAR(10)少 1 字节长度标记 - 混合类型表（比如含
CHAR(10)+VARCHAR(200)）会被 MyISAM 自动归为动态表，静态表的前提是“所有字段都不可变长”
什么时候该主动选静态表？
现在极少需要主动设计静态表。MyISAM 本身已不推荐用于新项目（事务、崩溃恢复、并发写入等缺陷太硬），而静态表的优势只在极窄场景成立：
- 日志归档表，只
INSERT+SELECT，字段全是INT/DATETIME/CHAR(n)，且生命周期短（如保留 7 天） - 嵌入式或低配环境（RAM key_buffer_size 缓存效率，且能接受空间换时间
- 备份恢复要求极高：静态表损坏后用
myisamchk --safe-recover成功率显著高于动态表
真正容易被忽略的是：你根本控制不了 MyISAM 用哪种格式。它完全由字段类型决定，而不是 CREATE TABLE 语句里的某个开关。检查 SHOW CREATE TABLE t 没用，得看 SHOW TABLE STATUS LIKE 't' 的 Row_format 字段——它只可能是 Fixed 或 Dynamic，没有第三种。
