我是一名自学成才的程序员，在构建可扩展的系统时，我始终遵循某些设计参数，这些参数更多地基于常识而不是研究。然而，我刚刚意识到我的系统中的一个组件可能不是必需的。
一般来说，我将用户数据分成组并将其分配给特定的 mysql 服务器。当负载均衡器后面的内容服务器收到请求时，我使用请求中的数据(如用户 ID)来解析存储用户数据的数据库，方法是查询 DynamoDB 上存储的中央表，该表可以处理大量负载。
但是，我还将用户数据分配给服务器内的数据库。就像我将在每台服务器中拥有 100 个数据库，它们都具有相同的表结构，并且我将为每个数据库分配 250 个用户。
最初的逻辑是，每个用户有 2k 条目的表在 500k 条目时的运行速度比 5000 万条目时要快得多。然而，我突然想到，以这种方式分解用户数据可能根本没有任何意义。 索引非常有效。我确信数据库实际上有某种内部逻辑，允许它以基本相同的速度访问数据，对吗？我这样做已经十年了，我才意识到这可能根本没有必要。有什么想法吗？我可以只创建一个包含所有表的数据库，还是应该继续按照我一贯的方式进行操作，在服务器上的 100 个数据库中进行分片？
最佳答案
这有点理论性，因此可能值得理解 Big-O complexity 的想法又名时间复杂度。
单个项目的聚集 B 树索引查找的时间复杂度为 O(log(n))，其中 n 是表中的行数。 DynamoDB 是一种基于哈希的实现，这使其更接近 O(1)，这意味着它的性能不会随着内容大小而明显变化。
现在进行数学计算，log(500k) = 5.7，其中 log(50mil) = 7.7 只要避免命中磁盘以将索引加载到内存中，单行查找的扩展性就非常好。
所以，您所说的单行查找有 25% 的差异。这很重要，但仍然可能低于往返另一个数据库系统(例如 DynamoDB)的开销。
当然，您的情况可能会有所不同，因为存在将索引保留在内存中等问题……因此您可能会在生产环境中看到差异。我强烈建议您设置一个测试，并验证您的表现。
关于mysql - 将用户数据分片到单个数据库服务器上的多个数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45006610/