这只是关于大规模数据库设计的设计问题。例如，如果您要构建一个可容纳1000万用户的数据库，您将如何构建它？
我主要的好奇心是像数据库复制这样的东西，这实际上加速了什么？
当构建这样大小的数据库时，请说这些字段是“用户名”“名称”“公司”“dob”“性别”而不是制作一个表，在那个规模上应该考虑什么？索引？
答案 0 :(得分：3)
1000万并不是特别大，但它足够大，你应该仔细考虑你的选择。
复制可以提供帮助 - 很多。假设您正在阅读用户表，而不是写入用户表，您可能会考虑只处理写入的主数据库。您的应用程序执行的任何读取都将来自N个从属框之一。
索引当然非常重要。您将需要经常搜索的任何列上的索引（在WHERE子句中，或作为与其他表的关系的结果（读取：JOINS））。关于如何分析应用程序所做的各种查询以及如何基于该分析智能地定义索引，已经写了很多文章。如果你只是在学习这些东西，那就去做一些阅读，然后回答问题更集中的问题。
除了单主复制（并仔细索引），当你开始变得非常大时，你可能会开始考虑partitioning - 但这是我只读过的东西，所以我不知道我想对此说太多。
答案 1 :(得分：0)
一千万条记录不一定是一个大型数据库。有些人会考虑一个包含数亿行或更多以及太字节或数PB存储空间的大型数据库。
除了典型的规范化之外，如果不能做任何事情来减少表的深度（行数），那么索引肯定会有所帮助。
答案 2 :(得分：0)
一如既往，这取决于用例..您将在数据库上运行哪些查询？
某些应用程序仅通过用户名或uid检索用户，因为键值存储是完美且可无限扩展的。
如果您有其他搜索查询，则可以将数据放入 SQL （相应列中包含索引）或使用外部搜索全文搜索引擎（ lucene，sphinx）。您还可以在不同的副本上构建不同的索引，这样每个索引都可以用于特定的查询，但仍然可以获得良好的插入性能（当然不是用户表，而是用户相关数据）。
如果你有复杂的查询，加入多个表，那么SQL可能是唯一的选择，但你仍然可以使用分片扩展用户名和用户相关的数据..这再次，取决于查询是什么。对于离线查询（统计数据，报告），您可以在每个分片上进行连接并合并结果集（map-reduce，gearman框架可以在这里提供帮助）。
最后，您可以混合使用所有这些方法，使用键值进行登录，使用SQL进行复杂查询，并使用复制来获得持久性和性能。