MyISAM静态表要求所有字段为定长类型（如CHAR、INT、DATE），每行分配固定字节数，读取快、崩溃易恢复，但空间浪费严重且末尾空格写入后查询自动截断；动态表则允许VARCHAR等变长字段，空间利用率高但易产生碎片、更新和恢复更复杂。
MyISAM静态表的行格式是固定长度
静态表要求所有字段都是定长类型，比如 CHAR、INT、DATE，不能出现 VARCHAR、TEXT、BLOB 等变长字段。MySQL 会为每行分配完全一致的字节数，等于所有列定义长度之和（例如 CHAR(10) 总占 10 字节，哪怕存的是 'a'）。
这种格式读取极快：无需解析行边界，可直接用偏移量定位第 N 行；崩溃后也容易恢复，因为损坏通常只影响单行，其余行结构不受干扰。
但代价明显：
-
CHAR(255)存'hello'也会占用 255 字节 - 末尾空格在写入时被补全，但查询返回时自动截断——
SELECT拿不到原始空格 - 如果业务依赖字段末尾空格语义（比如某些校验逻辑），静态表会悄悄破坏数据
MyISAM动态表的行格式是变长结构
只要表里有任何一个 VARCHAR、TEXT、BLOB 字段，MyISAM 就自动切到动态格式。每行开头有 1–2 字节的行头，记录本行实际长度；变长字段内容单独存放在行尾，通过指针索引。
好处是空间利用率高，VARCHAR(100) 存 5 个字符就只占约 6 字节（1 字节长度 + 5 字节内容）。
但问题随之而来：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 更新变长字段（如把
'abc'改成'hello world'）可能导致原位置放不下，MySQL 得把整行挪到别处，留下碎片 - 碎片多了，
SELECT扫描效率下降，OPTIMIZE TABLE成了必需操作 - 崩溃恢复更麻烦：行可能跨块、指针可能失效，
myisamchk -r修复耗时且不保证 100% 安全
如何确认当前表是静态还是动态格式
执行 SHOW TABLE STATUS LIKE 'your_table_name'，看 Row_format 字段：
- 返回
Fixed→ 静态表 - 返回
Dynamic→ 动态表 - 返回
Compressed→ 用myisamchk --compress压缩过的表（本质仍是动态格式）
注意：Row_format 是运行时推导值，不是建表语句显式指定的——MyISAM 根据字段类型自动决定，你无法用 ROW_FORMAT=FIXED 强制（那是 InnoDB 的语法）。
静态 vs 动态选择的关键权衡点
选静态表，前提是：表几乎只读、字段全是定长、对单行读取延迟极度敏感（比如高频缓存 key 查询）。
选动态表，更常见：只要用了 VARCHAR 就没得选；或者表有频繁 UPDATE 但能接受定期 OPTIMIZE TABLE。
最容易被忽略的一点：即使你刻意避开 VARCHAR，只要字段定义里带了 TEXT 或 BLOB（哪怕只是注释字段），MyISAM 也会降级为动态格式——这个隐式切换不会报错，但会彻底改变你的存储预期和维护节奏。
