Soh*_* Hg 8 index sql-server nonclustered-index sql-server-2014
我是 DBA 的新手。我想知道表的行数中是否有任何指定的点，当我们到达该点时，我们就可以使用索引。我知道表的行数和使用索引之间应该有一些依赖关系，但我不知道是否有标准表的行数。
索引是与表或视图关联的磁盘结构，可加快从表或视图中检索行的速度。索引包含从表或视图中的一个或多个列构建的键。这些键存储在一个结构（B 树）中，使 SQL Server 能够快速有效地查找与键值关联的一行或多行。
我想知道表的行数中是否有任何指定的点，当我们到达该点时，我们就可以使用索引。
表中的行数并不决定索引的使用。您的查询（模式）应该决定创建索引的需要，以便尽可能快地检索数据。
查询优化器依靠统计信息来生成最佳查询计划。
为数据库及其工作负载选择正确的索引是查询速度和更新成本之间的复杂平衡。
窄索引或索引键中列数很少的索引需要较少的磁盘空间和维护开销。
另一方面，宽索引涵盖更多查询。在找到最有效的索引之前，您可能必须尝试几种不同的设计。可以在不影响数据库架构或应用程序设计的情况下添加、修改和删除索引。
您应该使用SQL Server 的 DMV 来调整您的索引策略，甚至使用sp_BlitzIndex来获得更多见解。
参考：
我不知道什么是最好的，但数量很少就没有真正的价值。
使用索引会产生一些开销。是的，索引查找比表扫描更快，但使用索引会产生一些开销。索引维护显然有开销。
如果一个表有一个 PK，那么您应该使用它作为 PK，并且通常是集群的。
考虑美国各州的表（50 行）
ID PK 身份tinyint
名称 varchar(20)
区域tinyint
区域将用于对东北、东南等州进行分组
我个人永远不会在名称或区域上使用索引 - 表扫描仍然非常快。区域将是一个 FK，但不会自动创建索引（据我理解）。整个表正好是 2K 页面大小。如果经常使用 State.Name 上的排序，那么是的，会使用该索引，但我认为您甚至无法衡量性能增益。
超过一百万行然后是的开始预先构建索引。
然后考虑在一千到一百万之间建立索引。
即使有 10,000 行，也会有很多明显索引的情况。像 AddDate 这样的列不太可能更改，并且会大量用于搜索和排序，我将对其进行索引和维护（碎片整理）。一个包含超过 10,000 行的表，这些行将 State 引用为 FK，我会预先对该列建立索引。但既然你问这个问题，也许需要等待并针对现实生活中的查询进行优化。
我不希望您采取另一个极端，在可能使用的每一列上放置索引。索引有开销。索引会减慢插入和更新速度。高碎片索引可能比表扫描慢。
我发现这个网站上的很多用户都希望预先优化并进行理论讨论。这是给 DBA 新手的现实生活建议。