好的，我已经搜索过这个并且阅读了关于在 [MySQL] 数据库中存储二进制数据的一些观点。一般来说，我认为这是一个坏主意并尽量避免它，支持传统的文件传输并且只在数据库中存储对文件的引用。
但是，我正在从事一个项目，该项目需要与远程/云数据库进行数据库同步，不仅用于文件，还用于设置和其他用户内容。出于这个和其他原因，我觉得这可能是数据库中二进制存储的合适情况。
我已经为数据库同步编写了一个通用系统，它使用反射和 XML 运行良好。我还(违背我的直觉)将文件存储集成到这个系统中。同样，它运行良好 - 我将文件分成 64Kb BLOB，并将它们存储在一个表中，并带有 file_id 引用(链接到一个单独的表，其中包含文件名/大小/mime 类型等元数据)。
这使我能够在连接可用时发送点点滴滴，还允许我限制每个请求的大小以确保一切顺利进行。
到目前为止，我还没有发现任何问题，并且已经成功地双向导入和传输了超过 1gb 的数据(超过大约 10-15 个文件/16000 行)，但我担心它的可扩展性——它会不会变慢一旦那里有超过 20gb 的数据，或者如果我的查询结构良好，MySQL 可以处理它吗？
我决定将数据存储在数据库中的另一个原因是，我认为如果空间不足，我可以简单地向 MySQL 添加另一个 HDD/存储设备，以期实现高效的缩放/复制等。
我非常感谢任何关于这是好方法还是坏方法的意见或评论，我是否错过了在生产环境中使用后可能会遇到的任何明显问题？
编辑:我忘了说，文件大小可能在 1KB 到 ~1GB 之间
[粗略]结论 首先:非常感谢那些提供深思熟虑的答案的人。在这里选择可接受的答案非常困难，因为每个答案都可以提供不错的东西。
最后(尽管我抱有希望)，我认为纯 MySQL 存储服务器充其量只是一个不错的解决方案(我仍然不禁想知道为什么他们会费心包括 BLOB 类型)。
作为替代方案，我在@Nick Coons 文件系统方法和@tadman 建议的使用轻量级键/值数据库引擎(如 leveldb)的混合方法之间左右为难。如果在此项目中使用 leveldb 的实用性不是问题，这很可能是我将努力实现的方法。
我在此基础上接受了tadman的回答；他的回答也最适用于我的情况。
话虽如此，对于那些感兴趣的人来说:到目前为止，我只使用 MySQL 就取得了相当大的成功。我已经测试了一个存储超过 15gb 二进制数据的表，从大表中插入/检索数据(通过仔细查询)没有任何明显的负面影响。但是，我确信这仍然非常低效，而且所提到的任何一种替代方法都会好得多。
最佳答案
我想知道你为什么还要为数据库而烦恼，当你在上面添加到 block 、存储、检索和重新组装的层在一个定义良好的文件系统结构上也能正常工作时。 MySQL 希望它的所有数据都在一个单个 卷上，因此您不需要随时添加另一个驱动器，而且大量二进制数据的复制将非常慢，因为二进制日志最终会重复您需要存储的数据量。
最简单的方法往往是最好的方法。将其直接存储在文件系统中可能是最好的方法。如果您需要保留存储位置的索引，也许您会使用像 MySQL 这样的数据库，但是有很多方法可以完成同样的任务。技术含量越低越好。例如，不排除 SQLite因为嵌入式数据库在轻读写负载下性能非常好，并且在备份和恢复时具有“只是一个文件”的优势。
话虽如此，您所做的听起来与 LevelDB 可疑地相似，因此在您采用您的方法之前，您必须了解它与那种类型的键值文档存储有何显着不同。
关于c# - 在 mysql 数据库中存储大文件/二进制数据 : when is it ok?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17935978/