在这里开始一个新项目，我将存储大量的用户数据。我试图从一开始就使系统具有可伸缩性，因此我正在考虑一个相当新的想法，即将每个用户的数据(本质上是他们存储的文件的列表)存储在存储在特定于用户的目录中的单独SQLite数据库中，而不是在MySQL中存储一个包含用户ID的大型表。文件列表将存储与该文件相关的其他元数据，因此不能只使用文件系统。

我的想法是，当用户登录并查看他们的文件时，只显示单个SQLite数据库中的所有数据会更快，而不是让MySQL遍历“文件”表中的所有记录，根据ID取出一个用户的文件。每个用户都很容易有10,000+条目，最初至少有400个用户。那么，是400个包含10,000行的独立SQLite数据库，还是包含4百万行的单个MySQL表？请记住，所有400个用户很少(如果有的话)同时登录，让数据库必须处理不在那里的用户的数据似乎效率很低，即使这些数据已被索引。

SQLite的最大限制是锁定，但幸运的是，在这种情况下，只有一个进程写入数据库，所以这在这里应该不是问题。增加的备份单个SQLite数据库的管理是微不足道的，因为它们都将是增量文件系统备份的一部分。

有什么想法？意见？我是不是想多了？