我有一个站点，在单个目录中包含超过 10 万个静态文件（总共 60 万多个目录和文件）。我想我可以得到一个 VPS 来托管它而不会出现 inode 问题，但它不会是一个高流量的网站，所以我宁愿使用便宜的虚拟主机。
我正在考虑将文件存储在由 URL 路径索引的 MySQL 表中，并通过 PHP 提供服务。有更好的方法吗？
编辑： 澄清一下，这与在数据库中存储图像不同。我说的是 HTML 页面。
【问题讨论】：
我认为您最好的方法不是一开始就将它们存储在数据库中。在存储和服务文件方面，这是文件系统最擅长的。没有任何可能的原因表明数据库可以比普通文件系统更有效地执行此操作。
如果您要将它们存储在数据库中，那么考虑到大小限制，您会希望使用 BLOB 字段（例如 TEXT），并且为了提高效率，对 URL 进行哈希处理并将其存储在列中，而不是索引一些巨大的 VARCHAR 字段。
但是，正如您所说，它们是静态的，这实际上没有任何意义 - 因为它们是静态的，所以您的网络服务器会向页面添加一些长缓存标头，以便将它们存储在本地以供将来来自相同的点击客户。
[编辑 1 - 回应评论]
我用给出的信息回答了这个问题，并在 OP 未提供信息的情况下保持其通用性。
这取决于您索引了多少 VARCHAR - 这与您要索引的存储数据（URL/路径/页面名称）的长度有关。
如果您只为 100k 行索引少于大约 45 个字符，我想这真的不会有太大区别，哈希将使用更少的内存，但对于一个小集合的大小和性能可能不会真正产生那么多区别。
我在 OP 询问数据库时回答了这个问题，但仍然看不出有任何理由首先要将它们放在那里 - 它会比使用文件系统慢。0 为什么要连接到数据库，处理网络性能（除非它们在同一个盒子上——不太可能在 Web 主机中）查询索引，获取一行，通过数据库提供程序运行该数据并将输出流式传输到响应流，当 Web 服务器可以执行相同操作时结果是 CPU 周期少得多，与数据库相比，内存使用量只有一小部分？
【讨论】：
df -i 显示我有大约 500k inode 空闲，所以这是另一个问题。现在我还没有接近 500k 的限制，所以我很想去文件系统路线，直到它成为一个问题，虽然我希望以后迁移不会是一个巨大的痛苦。
是的 - 一个文件系统是一个数据库。我在过去 10 年中遇到的所有文件系统都可以轻松地在一个目录中容纳这么多文件 - 并且这些目录被实现为树（有些使用 B-Trees - 但是具有更大扇出的结构，例如 H-Trees更适合这种应用程序）。
（实际上，考虑到 coice，我建议将其构建为目录层次结构 - 例如，将 dirs 用于文件名的前 2 个字母或内容的 md5 哈希 - 如果没有，它会使管理内容变得更加容易影响性能）。
关系数据库都是关于存储小块结构化数据 - 它们不是管理大型可变数据的有效方法。
我手头没有任何基准，但就像我会选择一辆旅行车在运动摩托车上快速移动数 PB 的数据一样，我会使用合适的文件系统（例如 BTRFS 或 Ext4 - ZFS也可以完成这项工作，但它在 Solaris 以外的任何东西上都不是一个好的选择——而且 solaris 是否对网络服务器有意义是值得怀疑的）。
问题是廉价托管公司很少预先提供这种级别的信息。
请注意，文件系统行为的细微调整可以大大提高性能 - 在您的情况下，如果在 Linux 上运行，我建议显着降低 vfs_cache_pressure。但这需要 root 访问权限。
另一种方法是使用文档数据库而不是关系数据库（不是键/值存储）。这些是一种无模式 (NoSQL) 数据库，旨在提供对大型数据结构的快速复制和处理。因此，这将提供一个更具可扩展性的解决方案（如果这是一个问题）。例如乌鸦数据库。您可以使用键/值存储，但它们很少针对处理大数据负载进行优化。
如果你有一个非常充分的理由其他而不是你在这里描述的，我只会考虑 MySQL。
【讨论】：