MySQL存图片应优先用文件路径而非BLOB，因BLOB会导致数据库膨胀、备份缓慢、同步延迟、查询内存溢出及I/O性能骤降；路径存储更高效、可控且运维灵活。
MySQL 存图片会导致数据库文件急剧膨胀
每张 2MB 的 JPG 图片存进 LONGBLOB 字段，实际占用的磁盘空间不止 2MB：InnoDB 会额外记录事务日志、页填充碎片、备份时全量复制该块数据。1000 张图就是 2GB+ 的表文件，ibdata1 或独立表空间随之撑大，备份耗时翻倍，主从同步延迟明显升高。
更关键的是，mysqldump 导出时默认把 BLOB 内容转成十六进制字符串，一个字节变两个字符——2MB 图片导出后变成约 4MB 的 SQL 文本，极易触发内存溢出或超时中断。
-
innodb_file_per_table=ON只能隔离单表空间，无法缓解整体 I/O 压力 - 开启
binlog_format=ROW后，每张图更新都会写入完整二进制镜像到 binlog -
SELECT image FROM images WHERE id=123这类查询会强制加载整块 BLOB 到内存，容易触发sort_buffer_size或read_buffer_size不足告警
文件系统读写比 MySQL 更高效且可控
Web 服务器（如 Nginx）直接 sendfile() 零拷贝输出磁盘文件，而从 MySQL 读 MEDIUMBLOB 必须经过网络协议解析、字符集转换、结果集组装等多层处理，QPS 下降明显。实测同等硬件下，静态文件服务吞吐量通常是数据库查 BLOB 的 5–8 倍。
路径存储还带来运维弹性：你可以随时把 /uploads 挂载到 SSD 盘、迁移到 NAS、甚至替换为 CDN 回源地址，数据库表结构完全不用动。
- 文件名建议用哈希前缀（如
ab/cd/efghijklmnopqrstuvwxyz123456.jpg），避免单目录海量文件导致ls卡顿 - 务必校验
file_path字段是否以白名单目录开头（如/uploads/），防路径遍历漏洞 - 删除记录时，别只删数据库行——要同步
unlink()对应文件，否则产生“幽灵文件”
LOAD_FILE() 和 INTO OUTFILE 权限限制极严
想用 SQL 直接导入本地图片？LOAD_FILE('/home/user/photo.jpg') 大概率返回 NULL。因为 MySQL 默认只允许从 secure_file_priv 指定目录读取，且要求文件属主是 mysqld 进程用户（通常是 mysql），普通用户上传的图片根本不在这个路径下。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
同理，SELECT image INTO OUTFILE '/tmp/out.jpg' 也受限于该变量，且输出路径必须在服务端，应用层无法直接获取——你没法让 PHP 或 Python 脚本自动拿到这个文件做后续处理。
- 改
secure_file_priv需重启 MySQL，生产环境通常禁止 - 即使放开权限，
LOAD_FILE()会一次性把整个文件读进内存，大图易 OOM - 该函数不支持参数化，SQL 注入风险高，ORM 几乎都不封装它
真正需要存 BLOB 的场景其实非常少
除非你做的是离线设备管理后台（无独立文件服务）、或强一致性要求的金融单据系统（图片和审批流必须原子提交），否则都该优先走路径方案。连微信头像、商品主图这些高频访问资源，腾讯/阿里也都用对象存储 + 数据库存 URL。
如果非要用 BLOB，至少做到三点：限定单图上限（比如 WHERE LENGTH(image) ）、加 image_type 字段便于前端设置 Content-Type、查图片时用 SELECT image, image_type FROM images WHERE id=? 而不是 SELECT *——BLOB 字段永远不要出现在不需要它的查询里。
最常被忽略的一点：哪怕只存路径，也要在数据库加 file_size 和 upload_time 字段。不然哪天磁盘文件被误删，你连“这张图理论上应该有多大”都不知道。
