Ear*_*rlz 8 sql indexing performance database-design
我搜索了一下,没有看到任何类似的问题,所以这里.
你怎么知道什么时候把索引放在表中？您如何确定索引中包含哪些列？应该何时使用聚集索引？
索引可以降低select语句的性能吗？有多少索引太多,你需要多大的表才能从索引中受益？
编辑:
列数据类型怎么样？是否可以在varchar或datetime？
嗯，第一个问题很简单：
什么时候应该使用聚集索引？
总是。时期。除了极少数、罕见的边缘情况。对于每个操作，聚簇索引使表更快。是的！确实如此。有关背景信息，请参阅 Kim Tripp 出色的集群索引辩论继续。她还提到了她对聚集索引的主要标准：
INT IDENTITY 完美地实现了这一点 - GUID 没有。有关广泛的背景信息，请参阅GUID 作为主键。
为什么窄？因为聚簇键被添加到同一个表上每个非聚簇索引的每个索引页（以便能够在需要时实际查找数据行）。你不想在你的集群键中有 VARCHAR(200) ......
为什么独一无二？？请参见上文 - 群集键是 SQL Server 用于唯一查找数据行的项目和机制。它必须是独一无二的。如果您选择一个非唯一的群集键，SQL Server 本身会为您的键添加一个 4 字节的唯一标识符。小心点！
下一个：非聚集索引。基本上有一个规则：子表中引用另一个表的任何外键都应该被索引，它会加速 JOIN 和其他操作。
此外，任何具有 WHERE 子句的查询都是一个很好的候选者——首先选择那些执行了很多的查询。将索引放在出现在 WHERE 子句中的列上，在 ORDER BY 语句中。
下一步：测量您的系统，检查 DMV（动态管理视图）以获取有关未使用或缺失索引的提示，并一遍又一遍地调整您的系统。这是一个持续的过程，你永远不会完成！有关这两个 DMV（缺少和未使用的索引）的信息，请参见此处。
另一个警告：使用一卡车索引，您可以使任何 SELECT 查询变得非常快。但与此同时，必须更新所有涉及的索引的 INSERT、UPDATE 和 DELETE 可能会受到影响。如果你只选择 - 发疯！否则，这是一个微妙而微妙的平衡行为。您总是可以难以置信地调整单个查询 - 但您的系统的其余部分可能会受到影响。不要过度索引您的数据库！放置一些好的索引，检查并观察系统的行为方式，然后再添加一两个，然后再一次：观察系统的总体性能如何受其影响。