插入CLOB/BLOB慢的根源是应用层全量加载内容而非数据库配置；应改用参数化绑定、流式传输、分离元数据与内容，并合理选择字段类型及存储策略。
INSERT 含 LONGTEXT/LONGBLOB 的语句为什么会爆 max_allowed_packet？
MySQL 在解析 SQL 时会把整个 VALUES 中的字符串/二进制内容加载进内存做语法树构建，哪怕你只插 1 行，只要 content 是 5MB 的 JSON 文本，这条语句就可能超默认 4MB 的 max_allowed_packet。
- 别用字符串拼接构造超长
INSERT INTO t(content) VALUES ('...')—— 单引号内嵌大文本极易触发截断或乱码 - 改用参数化绑定：
INSERT INTO t(content) VALUES (?)，让驱动走二进制协议传输，绕过 SQL 解析层 - 确认客户端驱动支持流式写入：Java JDBC 要开
useServerPrepStmts=true&rewriteBatchedStatements=true；.NET MySQLConnector 要设Allow User Variables=True - 如果必须用字符串值（如调试），先用
HEX()转成十六进制字符串再拼，避免引号和换行破坏语法
为什么 Dapper 或 MyBatis 插入大字段后内存飙升？
ORM 默认把 byte[] 或 string 全量加载进内存再传给驱动，对 10MB 的 CLOB 就意味着应用进程多占 10MB 堆空间；更糟的是，某些驱动（如旧版 MySqlConnector）会额外拷贝一次做编码转换。
- Dapper 中启用流式写入：
connection.Execute("INSERT ...", new { content = new DbString { Value = hugeText, IsAnsi = true, IsUnicode = false } })，避免自动转string - MyBatis 配置
jdbcType="LONGVARCHAR"+fetchSize="-2147483648"（即 STREAM 模式），强制驱动分块读取 - Java 场景下，用
PreparedStatement.setBlob(int, InputStream)替代setBytes()，让数据库直读文件流 - 千万别在日志里打印完整 CLOB 字段——
log.info("inserted: {}", content)会把几 MB 内容全打到磁盘
该选 TEXT 还是 MEDIUMTEXT？BLOB 还是 LONGBLOB？
类型选错会导致隐式截断或存储浪费。MySQL 对 TEXT/BLOB 实际使用 off-page 存储，但字段声明类型决定了「单行最大允许长度」和「是否触发额外 I/O 分配」。
-
TINYTEXT（255 字节）和BLOB（64KB）基本不够用——压缩后的 JSON 或 Markdown 片段都可能超限 - 起步至少用
MEDIUMTEXT（16MB）或MEDIUMBLOB；除非明确要存 >16MB 文件（如原始视频），否则别盲目上LONGBLOB - 如果业务要求「单条记录必须包含完整文档」，且平均大小在 2–5MB，建议入库前用
COMPRESS()：INSERT INTO t(data) VALUES (COMPRESS(?))，字段仍用MEDIUMBLOB - 注意：COMPRESS() 后体积可能略增（如已压缩 JPG），此时应跳过压缩，直接存原始二进制
批量插入含 CLOB 的几十万行，怎么避免 OOM 和锁表？
一次性 INSERT INTO t VALUES (),(),... 插几万行带 CLOB 的记录，不只是慢，还会让 buffer pool 缓存大量低频页、撑爆 undo log、并长时间持有自增锁和 gap lock。
- 拆成单条事务提交：每批 200–500 行（高并发场景下比 1000 行更安全），每条语句只含一个 CLOB 值，避免单语句过大
- 禁用非必要二级索引：INSERT 前
ALTER TABLE t DROP INDEX idx_unneeded，导入完再重建；InnoDB 下DISABLE KEYS无效，别信 - 避开主键冲突重试陷阱：用
INSERT IGNORE或ON DUPLICATE KEY UPDATE id=id，而不是捕获异常再重试——后者会让事务反复回滚释放资源 - 终极方案：把 CLOB 写入对象存储（如 S3/MinIO），数据库只存 URL 和哈希，用触发器或应用层保证一致性
.ToString()、new String(bytes)、或日志里输出完整字段值，就已经踩进坑了。 
