结论：别把图片存 MySQL，备份时会连带拖垮整个库；真要存，必须拆事务、调大包、禁用 autocommit 控制节奏。因为 BLOB 字段使 mysqldump 生成超大十六进制文本，易触发 max_allowed_packet 限制、内存溢出和超时中断；同时大事务写入导致锁等待超时，且 SELECT COUNT(*) 等基础操作性能显著下降。
直接说结论：别把图片存 MySQL，备份时会连带拖垮整个库；真要存，必须拆事务、调大包、禁用 autocommit 控制节奏。
为什么 mysqldump 备份含图片的表会失败或极慢
因为 BLOB 字段内容直接塞进 SQL 文件，一张 5MB 的图 → 生成约 7MB 的 base64 或十六进制转义字符串；100 张图就接近 700MB 的纯文本 dump 文件。这不仅让 mysqldump 内存爆掉、超时中断，还会触发 MySQL 的 max_allowed_packet 限制（默认仅 4MB），报错 Packets larger than max_allowed_packet are not allowed。
实操建议：
- 备份前务必确认
max_allowed_packet设置足够大，例如启动mysqldump时加参数：--max-allowed-packet=512M - 禁止使用
--skip-extended-insert（它会让每行 INSERT 独立成句，BLOB 被重复转义多次，体积翻倍） - 优先改用
mysqlpump（MySQL 5.7+），它对 BLOB 支持更稳，且可并行导出 - 但最根本的解法是：不存图片到数据库 —— 备份只扫几 KB 的 URL 字段，而不是 GB 级二进制
INSERT 图片时触发 Lock wait timeout exceeded 怎么办
这不是锁冲突本身的问题，而是事务卡在写入大 BLOB 过程中，迟迟不提交，导致其他事务等不到锁。尤其当用 ORM 自动开启事务、又没显式 COMMIT 时，极易发生。
关键控制点：
- 绝对不要在事务里做文件读取：
file_get_contents($path)或fopen()耗时不可控，应提前读好二进制再进事务 - 禁用自动提交：
SET autocommit = 0，手动BEGIN→INSERT→COMMIT，避免隐性事务挂起 - 单次只插 1 张图，别批量插入多张
BLOB；若必须批量，每张图单独事务，或至少每 5–10 张COMMIT一次 - 检查
innodb_lock_wait_timeout值（默认 50），对图片写入类操作可临时设高些：SET innodb_lock_wait_timeout = 300
LOAD DATA INFILE 导入含图片的 CSV 为什么会失败
因为 LOAD DATA INFILE 不支持直接加载二进制数据；CSV 里的 BLOB 字段如果存的是 hex 格式（如 0xFFD8FFE0...），MySQL 默认按字符串解析，长度超限或编码错乱就会截断或报错 Incorrect integer value 等。
可行路径只有两条：
- 用
SELECT ... INTO DUMPFILE+ 客户端拼接 hex 字符串再INSERT，但开发成本高、易出错 - 更实际的做法：把图片先
INSERT到数据库获取自增id，再用客户端读取原始文件，执行UPDATE SET image_data = LOAD_FILE('/tmp/xxx.jpg') WHERE id = ?—— 注意secure_file_priv必须允许该路径，且文件需在 MySQL 服务端本地 - 无论如何，
LOAD DATA INFILE不适合图片导入，别硬刚
真正麻烦的从来不是“怎么把图塞进去”，而是“塞进去之后，谁来管它的锁、日志、备份和查询性能”。哪怕你调大了所有参数、拆了事务、绕过了包限制，只要表里有上万条 MEDIUMBLOB，SELECT COUNT(*) 都可能变慢——因为 InnoDB 得扫描每一行的聚簇索引记录，而 BLOB 数据虽存于溢出页，元信息仍占主索引空间。这不是配置问题，是设计水位越界了。
