8 我正在创建一个Web目录，该目录将允许各个用户注册一个帐户并将本质上的文本文档存储在mysql数据库条目中。 最初可能只有几百个用户，但我们希望在某个时候拥有10,000到100,000。而且每个用户都可以上传100-200个“文档”。 创建一个由用户编号索引的海量表会更有效吗？从理论上讲，这可以增长到20,000,000个条目。还是继续为每个用户创建带有各自文档的表格？ 我以为在数据库中有成千上万个表是不健康的，但是我真的找不到关于此的任何具体数据。 mysql — 基思 source
7 如果索引正确，MySQL可以轻松应对2000万行。我们有超过十亿行的表。 拥有一张桌子更干净。无需在基于用户（名称）的应用程序中做魔术。同样，更容易在documents表上进行任何统计。 我肯定会采用一种大表方法。如果您担心表格（物理）的大小，则应考虑对文档表格进行分区。http://dev.mysql.com/doc/refman/5.5/zh-CN/partitioning-types.html — 卡罗莉·纳吉（KárolyNagy） source 谢谢回复。然后，我肯定会使用一个表，然后研究分区方法。但是，有一个问题，正确索引的表到底意味着什么？我听到了很多引用，并假设这意味着数据库表需要正确定义的索引键。但是，除了最佳优化之外，还有更多的事情要做。 — 基思 使用正确的索引，我的意思是在user_id上至少包含一个复合索引，其中要过滤的列或在文档表上进行排序，并在用户表的用户名上进行索引（部分索引足以检查基数90-95 ％ 足够）。例如：sqlfiddle.com/#!2/9fb15/2（在我的情况与用户名基数部分索引5是50％） — 卡罗利·纳吉 我想我理解，谢谢您的帮助。再有一个问题，假设您为每个表都有一个主索引键，它是否仍有助于优化定义您知道将定期搜索的其他列（例如父类别）作为索引？为每个表定义主键或唯一键以及2-4个索引是否有缺点？ — 基思 索引会有所帮助，是的。实际上，您应该始终在要过滤的列上具有索引，否则查询将最终在完全扫描搜索中结束。唯一的缺点（除了索引大小之外）是插入和更新速度较慢，但是，由于使用InnoDB插件的5.1和默认情况下为5.5的MySQL具有快速的索引创建（dev.mysql.com/doc/refman/5.5/en/…），因此不是一个大问题了。 — 2013年