这只是一个关于大规模数据库设计的设计问题。例如，如果您要构建一个可容纳 1000 万用户的数据库，您将如何构建它？
我的主要好奇心是数据库复制之类的东西，这真的可以加快速度吗？
在构建这种大小的数据库时，除了制作一张表之外，说字段是“用户名”“名称”“公司”“dob”“性别”，在那个规模上还应该考虑什么？索引？
【问题讨论】：
标签： mysql database-design scalability
1000 万不是特别大，但足够大，您应该仔细考虑您的选择。
复制可以提供很多帮助。假设您读取用户表的次数多于写入的次数，您可能会考虑使用仅处理写入的主数据库。您的应用程序所做的任何读取都将来自 N 个从机之一。
当然，索引非常重要。您需要在任何经常搜索的列上建立索引（无论是在 WHERE 子句中，还是作为与其他表的关系的结果（阅读：JOINS））。关于如何分析应用程序进行的各种查询，以及如何根据该分析巧妙地定义索引，已经写了很多。如果您只是了解这些内容，请阅读一些内容，然后带着更集中的问题回到 SO。
除了单主复制（和仔细的索引），当你开始变得非常大时，你可能会开始考虑partitioning——但这是我只读过的东西，所以我不想说得太多了。
【讨论】：
与往常一样，这取决于用例。您要在数据库上运行哪些查询？
某些应用程序仅通过用户名或 uid 检索用户，因为 键值存储 是完美且无限可扩展的。
如果您有其他搜索查询，则可以将数据放入 SQL（在相应列上带有索引）或使用外部搜索全文搜索引擎（ lucene，狮身人面像）。您还可以在不同的副本上构建不同的索引，这样每个索引都可以用于特定的查询，但仍然可以获得良好的插入性能（当然不是针对用户表，而是针对用户相关数据）。
如果您有复杂的查询，要连接多个表，那么 SQL 可能是唯一的选择，但您仍然可以使用 sharding 对用户名和用户相关数据进行扩展。这个再次，取决于查询是什么。对于离线查询（统计信息、报告），您可以在每个分片上进行连接并合并结果集（map-reduce、gearman 框架可以在这里提供帮助）。
最后，您可以混合使用所有这些方法，使用键值对登录，使用 SQL 进行复杂查询，并使用复制来提高持久性和性能。
【讨论】：
一千万条记录不一定是一个大型数据库。有些人会考虑一个包含数亿行或更多行以及 TB 或 PB 存储的大型数据库。
除了典型的规范化之外，如果无法减少表的深度（行数），那么索引肯定会有所帮助。
【讨论】：