二进制文件（如pdf、图片、短视频）不宜直接当作“文档”存入数据库；推荐采用元数据+文件系统分离存储的架构，兼顾性能、可维护性与扩展性。
在现代应用开发中，常需为用户持久化多种类型的二进制文件——小至几KB的图标，大至2MB的短视频或数十MB的PDF报告。一个自然的疑问随之而来：能否将这些文件视作“文档”，直接存入数据库（如MySQL BLOB、Cassandra宽列存储或MongoDB GridFS）？ 答案是技术上可行，但工程实践中强烈不推荐。
为什么“把二进制当文档”存在根本性风险？
数据库的核心设计目标是高效处理结构化数据的事务、索引、关联与一致性保障，而非高吞吐的二进制流读写。将文件嵌入数据库会引发一系列连锁问题：
- 性能瓶颈：BLOB字段读写阻塞查询线程，大幅拖慢响应时间；备份/恢复耗时剧增（一个10GB的BLOB表可能让mysqldump运行数小时）；
- 内存与连接压力：数据库需将整个二进制块加载至内存（如MySQL max_allowed_packet限制），易触发OOM或连接超时；
- 运维复杂度飙升：文件损坏难以定位（数据库校验不覆盖BLOB内容）、版本回滚困难、无法利用CDN/对象存储加速分发；
- 扩展性受限：以Cassandra为例，若按user_id分区存储多份视频，单个分区极易突破100MB推荐上限，导致读取延迟陡增、节点负载不均。
✅ 推荐方案：元数据与文件存储解耦
最佳实践是数据库仅存储轻量元数据，文件实体交由专业存储层管理：
