一、先看结论
图片可以存进普通数据库，但代价极高，几乎没人这么做。
原因不是“技术上做不到”，而是数据库的设计目标与图片的存储需求根本不匹配。
二、普通数据库 vs 对象存储：设计目标完全不同
| 维度 | 普通数据库（MySQL） | 对象存储（S3/OSS/MinIO） |
|---|---|---|
| 设计目标 | 结构化数据的高效查询和事务 | 海量非结构化文件的存储和分发 |
| 存储单元 | 行（Row） | 对象（Object） |
| 数据特点 | 小、结构化、频繁更新 | 大、非结构化、一次写入多次读取 |
| 访问方式 | SQL 查询 | HTTP API（GET/PUT） |
| 扩展方式 | 垂直扩展（加 CPU/内存） | 水平扩展（加机器） |
| 成本 | 高（SSD、内存） | 低（机械硬盘、冷存储） |
三、为什么图片不适合存进数据库？
1. 体积问题：图片太大了
| 数据类型 | 典型大小 |
|---|---|
| 一行用户记录 | 几百字节 |
| 一张普通图片 | 几百 KB 到几 MB |
| 一张高清图片 | 几 MB 到几十 MB |
| 一段视频 | 几百 MB 到几 GB |
一张图片的体积，可能是一行用户记录的几千倍。
如果把 100 万张图片存进 MySQL，数据库会变得极其臃肿，备份、迁移、恢复都变得困难。
2. 性能问题：数据库被“拖慢”了
数据库的强项是快速查询结构化数据，而不是传输大文件。
内存浪费：数据库会把图片加载到内存缓冲池，挤占其他查询的空间
IO 瓶颈：大字段的读写会占用大量磁盘 IO
查询变慢：其他正常的 SQL 查询被拖累
3. 成本问题：数据库存储太贵了
| 存储类型 | 每 GB 月成本 |
|---|---|
| 数据库（SSD） | 高 |
| 对象存储（标准） | 低 |
| 对象存储（冷存储） | 极低 |
图片数量一多，用数据库存储的成本会迅速失控。
4. 扩展问题：数据库很难水平扩展
数据库的扩展通常是垂直扩展（加 CPU、内存、SSD），有物理上限。
对象存储天生水平扩展，加机器就能扩容，理论上无上限。
5. 访问模式不匹配
| 特性 | 数据库 | 对象存储 |
|---|---|---|
| 访问方式 | SQL 查询 | HTTP URL |
| 缓存 | 数据库缓存 | CDN 加速 |
| 分发 | 需要应用层处理 | 天然支持 CDN |
| 权限 | 数据库权限 | 签名 URL、ACL |
图片需要的是通过 URL 快速分发，而数据库不擅长这个。对象存储配合 CDN，可以让全球用户快速加载图片。
四、那数据库存什么？
数据库存的是图片的元数据，而不是图片本身。
CREATE TABLE images ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, filename VARCHAR(255), url VARCHAR(512), -- 对象存储的 URL size INT, mime_type VARCHAR(64), created_at DATETIME );数据库负责“索引”，对象存储负责“存储”。
五、什么情况下可以把图片存进数据库？
| 场景 | 是否推荐 | 原因 |
|---|---|---|
| 小图标、头像 | 可接受 | 体积小（几十 KB） |
| 数量少（<1万） | 可接受 | 不会显著拖慢数据库 |
| 需要事务一致性 | 可考虑 | 图片和业务数据必须同时提交 |
| 内网小系统 | 可接受 | 没有高并发和成本压力 |
| 海量图片 | 不推荐 | 性能、成本、扩展都有问题 |
| 高并发访问 | 不推荐 | 数据库扛不住 |
例外情况：如果图片很小（如用户头像缩略图），且数量不多，存进数据库的 BLOB 字段也可以接受。但一旦规模上去，就必须迁移到对象存储。
对象存储的核心优势
| 优势 | 说明 |
|---|---|
| 海量存储 | 理论上无上限，按需扩展 |
| 低成本 | 比数据库存储便宜得多 |
| 高可用 | 多副本、跨区域容灾 |
| CDN 友好 | 天然支持通过 URL 分发 |
| 按量付费 | 用多少付多少 |
| 生命周期管理 | 自动转冷存储、自动删除 |
