大字段导致查询变慢是因为mysql对text、blob及超768字节varchar触发行溢出，数据存于独立溢出页，主记录仅留20字节指针，select *会强制读取溢出页引发额外随机i/o。
大字段为什么会让查询变慢
MySQL 对 TEXT、BLOB 及超过 768 字节的 VARCHAR 会触发「行溢出」：实际数据被移到独立的溢出页，主记录只留 20 字节指针。这意味着一次普通 SELECT * 可能触发额外的随机 I/O——哪怕你根本不需要那个大字段。
常见错误现象：EXPLAIN 显示 type=ALL 但执行时间远超预期；SHOW PROFILE 中 Handler_read_next 次数异常高；慢日志里 Rows_examined 远大于 Rows_sent。
- 使用场景：日志表存 HTML 片段、用户上传的 JSON 配置、富文本内容
- 参数差异：
innodb_page_size默认 16KB，但溢出页最小单位是 16KB 整页，哪怕只存 1KB 数据也占满一页 - 性能影响：溢出页无法缓存在
innodb_buffer_pool的常规页中（除非开启innodb_large_prefix且格式为 Barracuda）
如何避免 SELECT * 触发溢出页读取
最直接的办法是明确列出需要的列，把大字段从查询中剔除。但这不是靠“习惯”，而是要进 SQL 审计流程——很多 ORM 自动生成 SELECT *，尤其在关联查询时容易漏掉。
实操建议：
- 用
SELECT id, name, status FROM article替代SELECT *，哪怕只少一个content字段，I/O 量可能下降 90% - 对必须查大字段的场景，加
WHERE条件并确保走索引，避免全表扫描连带拉出所有溢出页 - 检查
information_schema.INNODB_SYS_COLUMNS，确认哪些列实际被标记为extern（即已溢出），别凭字段类型猜
TEXT 和 VARCHAR(65535) 到底选哪个
很多人以为 VARCHAR(65535) 更“轻量”，其实只要长度超阈值（约 768 字节），InnoDB 就一律按 TEXT 处理——两者底层存储机制完全一致，都是溢出页 + 主记录指针。
关键区别其实在语义和约束上：
-
TEXT不允许设默认值（DEFAULT），也不支持在GROUP BY或ORDER BY中直接使用（需加SUBSTRING截断） -
VARCHAR支持NOT NULL和默认值，但超长后默认值本身也会被截断或报错，取决于sql_mode - 兼容性影响：MySQL 5.7+ 默认
innodb_file_format=Barracuda，才真正支持大VARCHAR溢出；老版本或Antelope格式下，VARCHAR超 768 字节直接建表失败
溢出页能压缩或延迟加载吗
不能原生延迟加载，但可以压缩。InnoDB 支持表级压缩（ROW_FORMAT=COMPRESSED），对溢出页效果显著——HTML 或 JSON 压缩率常达 60%～80%，减少磁盘 I/O 和缓冲池压力。
不过压缩有代价：
- CPU 开销上升，尤其写入频繁时；
INSERT/UPDATE会先压缩再落盘，解压只在读取时发生 - 必须用
Barracuda文件格式 +KEY_BLOCK_SIZE参数（如KEY_BLOCK_SIZE=4表示压缩到 4KB/页） - 备份工具如
mysqldump不感知压缩，导出的是解压后数据；物理备份（xtrabackup）才保留压缩结构
真正难处理的是业务层——没有类似 PostgreSQL 的 TOAST 透明延迟加载机制，所有溢出页都在第一次访问该行时强制读取。想绕开？只能拆表，把大字段单独拎到 article_content(article_id, content) 中，用应用层按需 JOIN。
