我以前从未设计过大型数据库，所以我从不关心索引。但是，现在我正在做一个需要大型数据库的大型项目。所以我正在确定我将在内部连接中使用它作为索引的每个表。
举个例子，一张大表有这样的字段：
Userid
Industryid
Teamid
Zoneid
任何带有 Id 的东西都是指向第二张桌子的标识。所以我已经索引了这些。
该表有 60 个字段，但其中 16 个被索引 + 1 个主字段。
如果有这么大的表包含所有这些索引是个好主意吗？我预计这张表在 1 年内将有超过 400 万条记录。我这样做的原因是为了让这张表与其他表之间的内部连接更容易和更快
在如此大的项目中使用索引的最佳方法是什么？
该表有 60 个字段，但其中 16 个被索引 + 1 个主字段。
这看起来有点过分，但如果你真的需要所有这些索引，那就没关系了。
索引不是免费的：每个额外的索引都会占用空间，并且在修改数据时需要维护1，以换取搜索数据时的加速（假设它使用正确）。为您的特定情况确定正确的权衡取决于您。
如果有这么大的表包含所有这些索引是个好主意吗？
在 FK 上建立索引几乎总是一个好主意，因此 DBMS 可以以良好的性能维护 FK。具体来说，每当删除父行或更新引用的键时，DBMS 都必须搜索子行。从理论上讲，如果您从不删除/更新父级，那么您也不需要 FK 上的索引，尽管某些 DBMS 无论如何都会强制您拥有它们。
这些索引可能（并且通常）对 JOINins 有用，但这实际上取决于您如何JOIN 以及您的 DBMS 的查询规划器的能力。2
在如此大的项目中使用索引的最佳方法是什么？
对于每个对性能敏感的查询，仔细检查查询执行计划并测量代表性数据量的实际时间。仅仅因为查询在小表上以一种方式执行，并不意味着当表增长时它将以同样的方式执行。
最后但同样重要的是，我强烈推荐阅读使用索引，卢克！
1每次向表中插入一行时，DBMS 都必须在索引 B-tree 中插入相应的键。当行被删除时，键将从索引中删除。更新索引字段时，需要删除旧键并插入新键。您的表上的索引越多，每当您在该表中插入/更新/删除一行时，DBMS 将不得不花费更多的时间来执行此“索引维护”。
2一个 JOIN 的执行方式有很多种：各种顺序的嵌套循环、合并连接、散列连接……不同的策略可能需要不同的索引甚至不同的种类索引（例如，B-tree 对哈希连接没有多大好处）。并非所有 DBMS 都能够使用所有这些策略，也不是在理论上可以使用现有索引的所有情况下都使用它们。因此，适用于一个 DBMS 的索引策略不一定适用于另一个 DBMS。有时，您可以保留索引，但您必须通过使用“查询提示”或使用对特定 DBMS 的查询优化器“友好”的语法，向正确的方向“轻推” DBMS，甚至尽管可能存在等效但更易于阅读的语法。例如，旧版本的 MySQL 将始终执行 IN 子查询作为嵌套循环的内部之一，即使在循环的反向顺序或合并连接会更快的情况下也是如此。那'在 MySQL 下（虽然我听说他们在 MySQL 5.6 中修复了这个问题）。OTOH，在 Oracle 下将 IN 重写为 JOIN 并不是很有用，因为 Oracle 在等效执行等效查询方面要好得多，即使存在语法差异也是如此。