是，InnoDB下实际存储相同但有隐式开销；MyISAM下varchar(255)比varchar(100)确实占更多磁盘空间。
varchar(255) 真的比 varchar(100) 占更多磁盘空间吗？
InnoDB 下，varchar 是变长字段，实际存储只用多少占多少（加 1–2 字节长度头），所以 varchar(255) 和 varchar(100) 在存 "abc" 时磁盘占用完全一样。但有两个隐藏开销不能忽略：
- 行格式影响：如果表用
COMPACT或REDUNDANT行格式，且该字段可能超过 255 字节，InnoDB 会为它额外分配 2 字节长度头（而不是 1 字节）——哪怕你实际只存 10 字符； - 排序/临时表代价：MySQL 在
ORDER BY、GROUP BY或创建内部临时表时，会按定义长度预估内存需求。varchar(255)可能触发磁盘临时表，而varchar(100)还能走内存；
常见错误现象：EXPLAIN 显示 Using temporary; Using filesort 突然变多，但 SQL 没改，只因某字段从 varchar(100) 扩成了 varchar(255)。
实操建议：
- 按业务真实最大长度设上限，别无脑
varchar(255)；比如手机号固定 11 位，就用varchar(11)； - 超过 255 字符再考虑是否真要
varchar，还是该上text（注意：text字段不参与内存排序，但有独立存储和索引限制）； - 用
SHOW TABLE STATUS查Row_format和Avg_row_length，结合INFORMATION_SCHEMA.COLUMNS的character_maximum_length做粗略估算。
MyISAM 的 varchar 长度声明会影响 .MYD 文件大小吗？
会，但方式不同。MyISAM 把 varchar 当“紧凑型固定长”处理：它在数据文件（.MYD）里仍按定义长度预留位置，只是末尾用字节标记实际长度。也就是说，varchar(255) 存 "a"，.MYD 里依然占 255 字节 + 1 字节长度标识（共 256 字节）；而 varchar(100) 同样存 "a"，只占 100 + 1 = 101 字节。
这导致 MyISAM 表体积对 varchar 定义长度极其敏感，尤其当字段多、行数大时，空间浪费呈线性放大。
实操建议：
- MyISAM 已不推荐新项目使用，但如果维护旧系统，务必收缩冗余
varchar长度，ALTER TABLE ... MODIFY COLUMN能直接减小 .MYD； - 注意 MyISAM 不支持在线 DDL，改长度会锁表，且
OPTIMIZE TABLE才能真正回收磁盘空间； - 别指望
ROW_FORMAT=FIXED能缓解——它会让所有varchar全部转成char，浪费更严重。
TEXT 类型在 InnoDB 和 MyISAM 中的存储差异到底在哪？
核心区别在“是否存主记录页内”：
- InnoDB：小于 40 字节的
text值会内联存储（进 B+ 树叶子页），否则存溢出页（off-page），主记录只留 20 字节指针； - MyISAM：所有
text都存在 .MYD 文件末尾的单独区域，主记录只存偏移量和长度，无论多短；
这意味着：同样一个短文本字段，InnoDB 可能比 MyISAM 更省 I/O（一次读页搞定），但一旦溢出，InnoDB 多一次随机 IO；而 MyISAM 总是至少两次 IO（先读主记录，再跳去末尾取 text）。
常见错误现象：
- 给用户昵称字段设
text，结果SELECT nickname FROM user慢得离谱——MyISAM 必须扫完整行再跳读 text 区； - InnoDB 下
text字段建前缀索引（如INDEX(nickname(50))）有效，但全字段索引无效，且无法用于ORDER BY nickname（除非加GENERATED COLUMN）；
实操建议：
- 昵称、简介等确定 ≤ 200 字符的场景，优先
varchar(200)，不是图省事写text； - 真要用
text，InnoDB 建议搭配ROW_FORMAT=DYNAMIC（默认），避免早期COMPACT下的隐式溢出； - MyISAM 表里慎用
text，尤其高并发点查场景，IO 放大明显。
alter column 长度时，InnoDB 和 MyISAM 哪个更容易卡住？
InnoDB 更容易卡，但原因不同：
- InnoDB：改
varchar长度若涉及行格式变化（比如从 ≤255 到 >255），需重建整张表（COPY算法），期间锁表、耗 CPU、生成大量 redo log； - MyISAM：改长度本质是重写 .MYD 文件，但不用事务日志，过程快得多，不过会锁表且不可中断；
更麻烦的是：MySQL 8.0+ 默认 innodb_strict_mode=ON，如果缩容（如 varchar(255) → varchar(50)）且已有超长数据，会直接报错 ERROR 1406 (22001): Data too long for column，而不是截断。
实操建议：
- 缩容前先查：
SELECT MAX(LENGTH(col_name)) FROM tbl，确认不超新长度； - 扩容尽量用
ALGORITHM=INSTANT（MySQL 8.0.12+ 支持），仅限增加长度且不改变字符集； - 生产环境改长度，InnoDB 务必避开高峰，MyISAM 至少选低流量时段，两者都不建议在从库直接操作。
字段长度不是写完就完的事。InnoDB 关心内存估算和溢出路径，MyISAM 直接映射到磁盘字节，同一个 varchar 声明，在两种引擎下引发的连锁反应完全不同。最常被忽略的，其实是排序和临时表那部分隐性开销——它不报错，但让查询慢得莫名其妙。
