text字段触发行溢出是因为compact格式仅在主数据页存储前768字节和20字节指针，超长内容存于独立溢出页，导致select *引发多次随机i/o并污染buffer pool；须改用dynamic行格式、避免大字段参与查询与索引、应用层压缩及合理类型定义。
为什么TEXT字段会触发行溢出
InnoDB 默认使用 COMPACT 行格式（MySQL 5.7+ 默认仍为 COMPACT，除非显式指定），对超过 768 字节的 TEXT 或 BLOB 值，只在主数据页存 20 字节指针，其余内容全扔进独立的溢出页。一次 SELECT * 看似读 1 行，实际可能触发 3–5 次随机 I/O——主页 + 多个溢出页。SSD 上虽延迟低，但 buffer pool 很快被污染，SHOW ENGINE INNODB STATUS 里能看到 Buffer pool hit rate 断崖下跌。
必须改用 DYNAMIC 行格式
COMPACT 和 REDUNDANT 都保留前 768 字节在主页，浪费空间且无法禁用自适应哈希；DYNAMIC（Barracuda 格式）才真正把全部大字段内容外置，主页只留 20 字节指针，是减少溢出干扰的底层前提。
- 确认当前行格式：
SHOW TABLE STATUS LIKE 'your_table';查Row_format列 - 升级到
DYNAMIC：ALTER TABLE your_table ROW_FORMAT=DYNAMIC; - 确保
innodb_file_format=Barracuda（MySQL 5.7 已默认启用，但旧配置可能残留） - 注意：该操作会重建表，建议在低峰期执行，并预留足够磁盘空间
别让 TEXT 字段参与索引或排序
任何涉及 ORDER BY content、GROUP BY content、WHERE content = ? 的查询，都会强制 MySQL 把整段内容拉进内存。若 sort_buffer_size 不够，直接触发 Using temporary; Using filesort，甚至 OOM。即使加了前缀索引，SELECT content 仍需回溢出页读取完整值。
- 永远避免
SELECT *，只查业务必需字段 - 等值判断改用虚拟列哈希：
ALTER TABLE logs ADD COLUMN content_sha256 CHAR(64) AS (SHA2(content, 256)) STORED;，再建索引 - 全文搜索改用
FULLTEXT，而非LIKE '%xxx%'—— 后者永远无法利用 B-tree 索引 - 若字段含大量重复前缀（如 JSON 开头固定），可抽离
prefix_hint VARCHAR(32)并建普通索引辅助过滤
字符集与压缩必须在应用层做
MySQL 内置 COMPRESS() 返回的是 zlib 二进制，但客户端必须配套解压，且容易因字段类型不匹配导致截断（比如原 TEXT 改 COMPRESS() 后没升成 MEDIUMBLOB）。更关键的是：压缩后字段仍是二进制，LIKE、前缀索引、FULLTEXT 全失效。
- 纯文本（日志、JSON、HTML）压缩率通常 60%~80%，应在 Java/Python 层用
DeflaterOutputStream或zlib.compress()处理 - 插入前校验字节长度：
content.getBytes(StandardCharsets.UTF_8).length （对应 <code>MEDIUMTEXT上限） - 字段类型同步升级：
MODIFY COLUMN content MEDIUMTEXT CHARACTER SET utf8mb4，避免中文被截断 - 已压缩的图片、PDF 不要再压——白耗 CPU，还可能损坏数据
真正卡住性能的往往不是“能不能存”，而是“每次查要不要把几 MB 内容从磁盘拖进内存”。溢出页本身不可消除，但你可以让它彻底不被触碰——靠行格式约束、靠查询写法隔离、靠应用层预处理。一旦漏掉其中一环，优化就前功尽弃。
