sql - 如何知道何时使用索引以及使用哪种类型？

Question

我搜索了一下，没有看到任何类似的问题，所以在这里。

你怎么知道什么时候在表中放置索引？您如何决定将哪些列包含在索引中？什么时候应该使用聚集索引？

索引是否会降低 select 的性能？声明？多少索引太多了，需要多大的表才能从索引中受益？

编辑:

列数据类型呢？可以在 varchar 上建立索引吗？或 datetime ?

Answer 1

嗯，第一个问题很简单:

When should a clustered index be used?

总是。时期。除了极少数、罕见的边缘情况。对于每个操作，聚簇索引使表更快。是的!确实如此。查看 Kim Tripp 的优秀 The Clustered Index Debate continues背景信息。她还提到了她对聚集索引的主要标准:

窄

静态(永不改变)

独一无二

如果可能的话:不断增加

INT IDENTITY 完美地实现了这一点 - GUID 没有。见 GUID's as Primary Key获取广泛的背景信息。

为什么窄？ 因为聚簇键被添加到同一个表上每个非聚簇索引的每个索引页(以便能够在需要时实际查找数据行)。你不想在你的集群键中有 VARCHAR(200) ......

为什么独一无二？？ 请参见上文 - 群集键是 SQL Server 用于唯一查找数据行的项目和机制。它必须是独一无二的。如果您选择一个非唯一的群集键，SQL Server 本身会为您的键添加一个 4 字节的唯一标识符。小心点!

下一个:非聚集索引。基本上有一个规则:子表中引用另一个表的任何外键都应该被索引，它会加速 JOIN 和其他操作。

此外，任何具有 WHERE 子句的查询都是一个很好的候选者——首先选择那些执行了很多的查询。将索引放在出现在 WHERE 子句中的列上，在 ORDER BY 语句中。

下一步:测量您的系统，检查 DMV(动态管理 View )以获取有关未使用或缺失索引的提示，并一遍又一遍地调整您的系统。这是一个持续的过程，你永远不会完成!见 here for info在这两个 DMV 上(缺少和未使用的索引)。

另一个警告:使用一卡车索引，您可以使任何 SELECT 查询变得非常快。但与此同时，必须更新所有涉及的索引的 INSERT、UPDATE 和 DELETE 可能会受到影响。如果你只选择 - 发疯!否则，这是一个微妙而微妙的平衡行为。您总是可以难以置信地调整单个查询 - 但您的系统的其余部分可能会受到影响。不要 超指数你的数据库!放置一些好的指标，检查并观察系统的行为方式，然后再添加一个或两个，然后再一次:观察总系统性能如何受其影响。