上周和一个做后端的朋友吃饭，他吐槽说最近被一个需求折磨得够呛——客户要求把所有上传的文件直接存到数据库里，而不是放在文件服务器上。他反复解释性能问题，客户就是不买账，觉得数据库最安全，什么都往里塞才放心。我听完笑了，这场景太熟悉了，几乎每个程序员职业生涯里都会遇到一两次。文件存数据库这事儿，看似简单，背后的坑却比想象中深得多。
先说最直观的问题——数据库体积膨胀。你想想，一个普通文本文件可能只有几KB，但一张高清图片动辄几MB，一段视频更是几十上百MB。把这些二进制数据直接塞进数据库的 BLOB 字段里，数据库文件就像吹气球一样鼓起来。备份和恢复的时间从几分钟变成几小时，查询速度也随之下滑。我见过一个真实案例，某公司把产品图片全存进数据库，半年后数据库从 20 GB 涨到 200 GB，每次全量备份要跑将近两个小时，DBA 差点崩溃。而且数据库越大，维护成本越高，索引重建、统计信息更新这些常规操作都变得举步维艰。
性能问题更是躲不开的噩梦。数据库的设计初衷是处理结构化数据，比如数字、日期、短字符串，对这些东西它游刃有余。但文件是二进制大对象，数据库读取时必须把整个文件加载到内存才能操作。假设你的应用每秒要处理 100 个用户上传的图片，每张 5 MB，那数据库每秒需要处理 500 MB 的数据量，这对大多数数据库来说是灾难性的。更糟的是，查询一个包含 BLOB 字段的表时，即使只需要读取其他列，数据库也会把 BLOB 数据一起读出来——因为它不知道你会不会用到，只能一股脑全拉出来。这种“连带伤害”让简单查询都变得慢吞吞的。
还有个容易被忽略的点：事务锁定机制。当多个用户同时往数据库里写文件时，事务锁会变得非常复杂。文件写入通常需要几秒甚至几十秒，这段时间内，该行数据甚至整个表都可能被锁住。其他用户恰好在读同一张表，就只能排队等着。我在一个电商项目中就遇到过这种情况：用户上传商品图片时，整个商品表被锁了，导致其他用户无法查看商品详情。后来一查，原来是上传大图的事务占着锁不放，后面的查询全堵死了。换成文件存储后，问题迎刃而解。
当然，有人会说数据库有 BLOB 的优化方案，比如 MySQL InnoDB 对 BLOB 有特殊处理，超过一定大小的数据会自动放到外部存储页。但这只是把问题从表层挪到了底层，数据库引擎仍然要处理这些大对象，只是分担了一部分压力。而且这种优化往往以牺牲某些功能为代价，比如不能对 BLOB 建立索引，无法做全文搜索，连简单的排序都做不到。说白了，数据库对文件的支持，就像让专业短跑运动员去举重——不是不能，但真的不是那块料。
不过，事情也不能一刀切。有些场景下，文件存数据库反而是最优解。比如金融系统或医疗系统，对数据一致性和完整性要求极高，文件必须和关联记录绑定在一起，不能出现“数据库里有记录但文件丢了”的情况。这时，用数据库的事务机制保证文件和元数据的原子操作，虽然牺牲了部分性能，但安全性和可审计性更有保障。还有文件体积小、访问频率低的场景，比如存储用户头像的缩略图或配置文件，每个文件只有几十 KB，放在数据库里也没什么压力。
但大多数情况下，更明智的做法是“元数据入库，文件落盘”。也就是把文件的路径、大小、哈希值、上传时间这些描述信息存进数据库，文件本体放在文件系统、对象存储或 CDN 上。这样数据库保持小巧灵活，查询速度快；文件存储则可根据需求选择——本地磁盘、NFS、S3、OSS 都行，各有优势。而且这种方案天然支持分布式扩展，文件存到对象存储后，应用服务器可以水平扩展，完全不用担心单点瓶颈。
说句实在话，技术选型从来不是单纯的技术问题，它背后往往牵涉团队的历史包袱、客户的心理预期、甚至运维人员的习惯。我见过不少团队，明明知道文件存数据库不好，却因为“以前就这么干的”“怕改出问题”一直拖着不重构。结果数据库越来越臃肿，性能越来越差，最后不得不花更大代价迁移。与其如此，不如一开始就想清楚：文件到底该放哪？数据库是存数据的，不是当文件柜的。让专业的系统做专业的事，这才是架构设计的核心。等到数据库崩了再后悔，那可就真的来不及了。
