在业务开发中，不少开发者会纠结图片、视频、压缩包等二进制文件应该存在哪里，有一部分人会选择直接将这些文件存入mysql数据库，这种做法虽然初期实现简单，但长期来看存在诸多问题，并不被业内推荐。
mysql存储二进制文件的核心问题
数据库膨胀问题
图片等二进制文件通常体积较大，少则几十KB，多则几MB甚至更大。如果将这类文件存入mysql，会直接导致数据库的体积快速增长，带来一系列连锁问题。
首先，数据库备份和恢复的时间会大幅增加。mysql的逻辑备份工具mysqldump在导出包含大二进制字段的表时，速度会明显下降，生成的备份文件体积也会膨胀数倍，恢复时需要更长的时间，甚至可能出现恢复失败的情况。
其次，数据库膨胀会影响查询性能。mysql的缓冲池（innodb_buffer_pool）通常用于缓存热点数据，二进制文件占用大量空间会导致缓冲池被无用的大字段数据占满，真正的热点业务数据无法被缓存，进而使得查询响应时间变长。
我们可以通过一个简单的示例查看存储二进制文件后表的体积变化：
-- 创建存储图片的表
CREATE TABLE image_storage (
id INT PRIMARY KEY AUTO_INCREMENT,
image_name VARCHAR(255) NOT NULL,
image_data LONGBLOB NOT NULL,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 插入一张1MB大小的图片（假设图片二进制数据已读取到变量中）
-- 此处省略实际插入二进制数据的代码，仅展示表体积查询
-- 查询表的大小
SELECT
table_name,
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS table_size_mb
FROM information_schema.tables
WHERE table_schema = 'your_database_name' AND table_name = 'image_storage';
读写性能损耗
mysql处理二进制数据的效率远低于处理结构化文本数据。当读取存储的二进制文件时，mysql需要将完整的二进制数据从磁盘加载到内存，再返回给应用层，这个过程会占用大量的IO资源和网络带宽。
如果是高并发场景，多个请求同时读取大二进制文件，很容易导致数据库的连接数占满、IO负载过高，进而影响整个数据库服务的稳定性，甚至导致其他业务查询也出现超时。
扩展和维护成本高
mysql的横向扩展能力较弱，当存储的二进制文件越来越多，数据库需要扩容时，往往只能进行垂直扩容，也就是增加单台服务器的磁盘、内存、CPU资源，成本很高。而文件系统可以很方便地对接对象存储、分布式文件系统等方案，扩展成本更低。
另外，如果需要对存储的图片进行裁剪、压缩、格式转换等操作，从mysql中读取二进制数据后再处理，比直接从文件系统读取文件路径处理要复杂很多，也会增加额外的开发成本。
二进制文件存储方案对比
我们将mysql存储和文件系统存储的核心维度进行对比，可以更直观地看到两种方案的差异：
| 对比维度 | mysql存储二进制文件 | 文件系统/对象存储 |
|---|---|---|
| 存储密度 | 低，大文件会快速撑大数据库 | 高，适合存储各类大体积文件 |
| 读写性能 | 差，占用大量IO和带宽 | 好，文件系统IO专门针对文件设计 |
| 备份恢复 | 慢，备份文件体积大 | 快，可单独备份文件，不影响业务库 |
| 扩展能力 | 弱，只能垂直扩容 | 强，可对接分布式存储、对象存储 |
| 维护成本 | 高，需要额外处理大字段性能问题 | 低，文件操作逻辑简单 |
推荐的二进制文件存储方案
实际项目中，更推荐的做法是将图片等二进制文件存储到文件系统或者对象存储中，只在mysql中存储文件的访问路径。示例如下：
-- 创建存储文件路径的表
CREATE TABLE image_meta (
id INT PRIMARY KEY AUTO_INCREMENT,
image_name VARCHAR(255) NOT NULL,
file_path VARCHAR(512) NOT NULL COMMENT '文件在文件系统或对象存储中的路径',
file_size INT NOT NULL COMMENT '文件大小，单位字节',
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
对应的文件上传逻辑可以这样实现：
<?php
// 假设接收到的上传图片为$_FILES['upload_image']
$uploadDir = '/data/upload/images/';
// 生成唯一文件名
$fileName = uniqid() . '_' . $_FILES['upload_image']['name'];
$filePath = $uploadDir . $fileName;
// 将文件移动到指定目录
move_uploaded_file($_FILES['upload_image']['tmp_name'], $filePath);
// 将文件路径存入mysql
$pdo = new PDO('mysql:host=127.0.0.1;dbname=your_database;charset=utf8', 'user', 'password');
$sql = 'INSERT INTO image_meta (image_name, file_path, file_size) VALUES (?, ?, ?)';
$stmt = $pdo->prepare($sql);
$stmt->execute([$_FILES['upload_image']['name'], $filePath, $_FILES['upload_image']['size']]);
?>
这种方案下，mysql只存储轻量的路径信息，不会因为二进制文件导致膨胀，读写性能也不会受到影响，后续如果需要扩展存储，只需要对接新的文件系统或对象存储，修改文件的存储路径即可，维护成本更低。
当然，如果业务场景中存在二进制文件需要严格和数据库事务保持一致，且文件体积非常小（比如几KB的图标）的情况，也可以酌情考虑存入mysql，但绝大多数场景下，都不建议将图片等二进制文件直接存储到mysql中。