应使用TEXT类型而非BLOB存储大文本，因其支持字符集、索引和排序；需调大innodb_log_file_size至≥256MB避免写入卡顿；查询时必须显式指定字段或截取内容，禁用SELECT *；全文检索应交由Elasticsearch等专用引擎处理。
用 BLOB 存大文本是错的，先换 TEXT 类型
MySQL 的 BLOB 和 TEXT 看似都能存长内容，但底层处理逻辑完全不同：BLOB 按二进制处理，不走字符集校验，排序、比较、索引都受限；而 TEXT（尤其是 MEDIUMTEXT 或 LONGTEXT）支持完整字符集、可建前缀索引、能参与 ORDER BY 和 GROUP BY。实际写入 10MB+ 日志或 HTML 片段时，用 BLOB 会导致 mysqld 内存暴涨、复制延迟加剧。
实操建议：
- 把
BLOB字段直接改类型：ALTER TABLE t MODIFY content MEDIUMTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 如果已有数据含非法字节（比如原始二进制 dump），先用应用层清洗，别依赖 MySQL 自动转换
-
TINYTEXT（64KB）不够用就跳过TEXT（64KB），直接选MEDIUMTEXT（16MB）——InnoDB 行格式下，TEXT和MEDIUMTEXT存储开销一致，只是长度限制不同
innodb_log_file_size 不够大会卡住大文本写入
写入 >1MB 的 MEDIUMTEXT 字段时，MySQL 会把整条记录缓存在 redo log buffer 里，再刷到磁盘。如果 innodb_log_file_size 太小（默认 48MB），单次写入就可能撑爆一个 log file，触发强制 checkpoint，造成线程阻塞、响应毛刺明显。
常见错误现象：
- 执行
INSERT或UPDATE含大文本字段时，连接卡在Writing to net或Updating状态数秒 - 慢查询日志里出现 “
Rows_examined: 0 Rows_sent: 0” 却耗时超 500ms -
SHOW ENGINE INNODB STATUS中Log sequence number增长突兀，Last checkpoint at落后严重
调整建议：
- 设为单个文件 ≥ 256MB：
SET GLOBAL innodb_log_file_size = 268435456;（需停机重建 log files） - 同时调高
innodb_log_buffer_size（如 16MB），避免频繁刷 buffer - 注意：增大 log file 会延长崩溃恢复时间，但对 OLTP 场景影响远小于写入卡顿
查大文本字段必须加 LIMIT 和字段裁剪
SELECT * FROM t WHERE id = 123; 这种语句在有 MEDIUMTEXT 字段时极其危险——哪怕只查 1 行，MySQL 也会把整个文本加载进连接内存，再发给客户端。100 个并发查 5MB 文本，瞬间吃光 500MB RAM，触发 OOM Killer 杀 mysqld。
正确做法：
- 永远显式列出字段，避开大文本：
SELECT id, title, created_at FROM t WHERE id = 123; - 真要查内容，用
SUBSTRING(content, 1, 2000)截取预览，或加LIMIT 1防误操作 - 应用层做分页时，别用
OFFSET跳过大量行再取大字段——改用基于id的游标分页：WHERE id > ? ORDER BY id LIMIT 20 - 考虑把高频查询的文本摘要（如前 200 字 + md5）单独建列，加索引加速过滤
别让 MySQL 做全文检索，交给 Elasticsearch 或 Meilisearch
MySQL 原生 FULLTEXT 索引对中文支持弱（依赖 ngram 插件且配置复杂），且 MATCH ... AGAINST 在 LONGTEXT 上性能随数据量陡增——100 万行、平均每行 2MB 文本时，简单关键词搜索可能耗时 3s+，还锁表。
替代方案更稳：
- 写入时同步推一份纯文本到
Elasticsearch（用 Logstash、Debezium 或应用双写），查的时候走 ES，结果 ID 回查 MySQL 主表 - 小团队可选
Meilisearch：部署简单、中文分词开箱即用、HTTP API 直接返回高亮片段 - 如果必须 MySQL 内解决，至少用
LIKE '%keyword%'+ 前缀索引（ADD INDEX idx_content_prefix (content(100))），比FULLTEXT更可控
真正难的不是存多少，而是怎么不让大文本拖垮连接池、redo log、复制线程和开发直觉——这些地方一松懈，问题就藏在“还能用”底下，等流量翻倍才爆发。
