在这里开始一个新项目，我将存储大量用户数据。我正试图从一开始就让系统具有可扩展性，因此我正在考虑将每个用户的数据（本质上是他们存储的文件列表）存储在单独的SQLite数据库中的新想法，该数据库存储在特定于用户的目录中，而不是MySQL中的一个带有用户ID的大表中。文件列表将存储与该文件相关的其他元数据，因此不能仅使用文件系统。
我的想法是，当用户登录并查看他们的文件时，只在一个SQLite数据库中显示所有数据会更快，而不是让MySQL遍历"文件"表中的所有记录，按ID提取一个用户的文件。每个用户很容易就有10000多个条目，最初至少有400个用户。那么400个有10000行的SQLite数据库，还是一个有400万行的MySQL表？请记住，所有400个用户很少（如果有的话）同时登录，让数据库处理不在那里的用户的数据似乎效率很低，即使它被索引了。
SQLite最大的限制是锁定，但幸运的是，在这种情况下，只有一个进程会写入数据库，所以这在这里应该不是问题。备份单个SQLite数据库的额外管理是微不足道的，因为它们无论如何都将是增量文件系统备份的一部分。
想法？意见？我是不是想得太多了？
我的想法是，当用户登录并查看他们的文件时，只显示单个SQLite数据库中的所有数据会更快，而不是让MySQL检查"文件"表中的所有记录，按ID提取一个用户的文件。
不，如果您正确地索引MySQL数据库，则不会。如果设置正确，400万条记录应该不会带来任何问题。
我一直在用我构建的应用程序做这件事。每个用户都有自己的SQLite数据库。我这样做的原因是，我允许用户将数据备份到Dropbox，并将其同步到iOS应用程序中匹配的SQLite数据库（通过Dropbox）。
优点：
-用户数据是孤立的，而且很容易同时支持和查看单个数据库
-数据随时可以推送到Dropbox。它很容易携带。
缺点：
-如前所述，模式更改是一种痛苦。我必须在每个SQLite数据库中保留一个名为"版本"的表，并跟踪一个表示其模式的版本号。模式更改包括编写粗糙的更改查询，并对存储在我的服务器上的所有数据库文件进行迭代
-打开这么多独立的数据库，服务器可能会承受更大的负载。我怀疑索引MySQL数据库会更快。
总的来说，它是可行的，但由于模式更改的问题，我实际上希望将所有数据合并到一个MySQL数据库中。
祝你好运。
我认为，与查询已经打开了最近数据库和表的单个服务器实例（MySQL）相比，打开和关闭数千个数据库文件（SQLite）的成本要高得多。
400名用户也不是。在这些级别上，您可能不会看到任何性能问题。
我想这根本不会很好地扩展。假设您超出了当前服务器的容量，并尝试启用第二个数据库服务器。哪个有哪些用户ID？MySQL的主/从复制意味着您不必担心这个问题。
我还认为，运行此操作系统的操作系统将很难以优化的方式保存所有这些文件。使用MySQL，您可以轻松地优化表，处理碎片等问题。如果您使用SQLite，您可能会花费更多的资源来查找和加载文件内存，而不是MySQL查找表的这一部分。
这是一个有趣的思想实验，但我认为它不会达到你想要的效果。如果你真的想做一些可扩展和快速的东西，试着看看MongoDB：http://www.mongodb.org/.它速度快、灵活、伸缩性好。此外，你可以保留一个文件列表，并搜索上传文件的用户——如果你想做一个像"只存储我们以前没见过的文件"这样的Dropbox，这可能会很有用。