不建议在主表中直接使用TEXT和BLOB字段，因其采用溢出页存储，导致读写、排序、备份等操作频繁触发额外随机I/O、整行重写、磁盘临时表及binlog放大，高并发下易引发性能雪崩。
MySQL不建议在主表中直接使用TEXT和BLOB字段，不是因为它们“不能存”，而是每次读、写、排序、备份甚至MVCC版本链访问，都可能触发额外随机I/O、缓存污染、磁盘临时表或整行重写——这些行为在高并发或大数据量下会快速演变成雪崩。
为什么SELECT *一碰就慢
只要表结构里定义了TEXT或BLOB字段，即使SQL里没写它，InnoDB仍可能加载整行（含溢出页）：
- ORM自动映射、驱动预取、某些隔离级别下的MVCC一致性读，都会拉取完整行数据
- 行格式为
COMPACT或DYNAMIC时，内容超768字节即移至溢出页，主记录只留20字节指针 - 一次
SELECT *实际要读聚簇索引页 + 1个或多个溢出页，SSD上也可能打爆innodb_buffer_pool_size -
EXPLAIN显示type=ALL但rows不大，而Query_time动辄秒级，Rows_examined远大于Rows_sent，基本就是这个原因
为什么ORDER BY或GROUP BY TEXT会落盘甚至OOM
MySQL的MEMORY引擎根本不支持TEXT/BLOB类型，只要语句涉及这类字段的排序或分组，优化器会直接放弃内存临时表：
- 哪怕只是
ORDER BY created_at，但表里有content TEXT，也会触发Using temporary; Using filesort -
tmp_table_size和max_heap_table_size设再大也没用，必定创建磁盘临时表（MyISAM格式） - 如果
sort_buffer_size不够，整个TEXT内容会被拉进内存排序，极易OOM - 慢查询日志中
Created_tmp_disk_tables持续上涨、Sort_merge_passes飙升，就是典型信号
为什么UPDATE变慢、备份卡住、主从延迟暴涨
TEXT/BLOB字段会让写入链路和复制链路全面承压：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
UPDATE任意字段时，若该行含TEXT，InnoDB常触发整行重写（row relocation），引发page split和碎片 - binlog默认记录完整字段值（
binlog_row_image = FULL），一条含1MBTEXT的UPDATE可能让binlog瞬间膨胀数倍 -
max_binlog_size被快速填满，频繁切换文件；主从复制延迟直线上升，尤其在日志类高频写入场景 -
mysqldump备份时需逐行读取溢出页，100GB表+大量
TEXT字段，备份可能卡在“Sending data”十几分钟不动
怎么选型、拆分、查询才不算踩坑
真要存，必须约束使用方式，不能靠“以后再优化”：
- 类型选错比不用更糟：
BLOB不走字符集校验，LIKE 'xxx%'、前缀索引、ORDER BY全失效；纯文本一律用MEDIUMTEXT并显式指定CHARACTER SET utf8mb4 - 垂直拆表最稳妥：主表只留
id和摘要字段（如title,digest），大内容单独建article_content表，JOIN按需拉取 - 超1MB的内容别进数据库：主表只存
content_url和content_md5，文件走OSS/S3/MinIO - 查询永远显式列出字段，禁用
SELECT *；必要时用SUBSTRING(content, 1, 500)截取展示
真正难处理的不是单条大字段，而是它像毛细血管一样渗透进查询路径、缓存策略、复制机制和运维流程——一旦上线，再想拆，代价远高于初期设计时多花十分钟做垂直切分。
