什么专栏通常做出好的指标？
作为“ 索引是什么以及如何使用它们来优化数据库中的查询？ ”的后续操作，我正在试图了解索引，哪些列是好的索引候选？ 特别是对于MS SQL数据库？
一些谷歌search后，我已经阅读的一切表明，通常增加和独特的列做了一个很好的索引（像MySQL的auto_increment），我明白这一点，但我使用MS SQL和我使用的主键GUIDs，所以它似乎该索引不会使GUID列受益…
索引可以在查询优化中发挥重要作用，并从表中快速search结果。 因此，select要索引的列是最重要的一步。 有两个主要的地方我们可以考虑索引：在WHERE子句中引用的列和在JOIN子句中使用的列。 简而言之，这样的列应该被索引，您需要search特定的logging。 假设我们有一个名为买家的表，其中SELECT查询使用如下所示的索引：
SELECT buyer_id /* no need to index */ FROM buyers WHERE first_name='Tariq' /* consider to use index */ AND last_name='Iqbal' /* consider to use index */ 由于在SELECT部分中引用了“buyer_id”，MySQL将不会使用它来限制所选的行。 因此，没有很大的需要索引它。 下面是另外一个与以上不同的例子：
SELECT buyers.buyer_id, /* no need to index */ country.name /* no need to index */ FROM buyers LEFT JOIN country ON buyers.country_id=country.country_id /* consider to use index */ WHERE first_name='Tariq' /* consider to use index */ AND last_name='Iqbal' /* consider to use index */
根据上面的查询first_name，last_name列可以被索引，因为它们位于WHERE子句中。 另外来自国家/地区表的country_id字段可以考虑用于索引，因为它位于JOIN子句中。 因此，可以在WHERE子句或JOIN子句的每个字段上考虑索引。
以下列表还提供了一些提示，当您打算在表中创build索引时，应始终记住这些提示：
- 只索引WHERE和ORDER BY子句中所需的那些列。 索引列丰富会导致一些缺点。
- 尝试利用MySQL的“索引前缀”或“多列索引”function。 如果您创build索引（如INDEX（first_name，last_name）），则不要创buildINDEX（first_name）。 但是，在所有的search情况下，不build议使用“索引前缀”或“多列索引”。
- 对于您在其中考虑索引的列使用NOT NULL属性，以便不会存储NULL值。
- 使用–log-long-format选项logging不使用索引的查询。 通过这种方式，您可以检查此日志文件并相应地调整您的查询。
- EXPLAIN语句可以帮助您揭示MySQL将如何执行查询。 它显示了如何和以什么顺序join表格。 这对确定如何编写优化查询以及是否需要对列进行索引非常有用。
更新date（2月23日）：
任何索引（好/坏）都会增加插入和更新时间。
根据您的索引（索引和types的数量），search结果。 如果你的search时间会因为索引而增加，那么这就是糟糕的索引。
可能在任何一本书中，“索引页”都可以有章节起始页，主题页码开始，子主题页也开始。 索引页面中的一些说明可以帮助你，但是更详细的索引可能会让你感到困惑或者吓到你。 索引也有记忆。
指数select应该是明智的。 请记住，并非所有列都需要索引。
有些人在这里回答了类似的问题： 你怎么知道一个好的指数是什么？
基本上，这取决于你将如何查询你的数据。 您需要一个快速标识与查询相关的数据集的一小部分的索引。 如果你从不用datestamp查询，你不需要索引，即使它大多是唯一的。 如果你所做的只是获得某个date范围内发生的事件，那么你肯定会想要一个事件。 在大多数情况下，性别指数是毫无意义的 – 但是如果你只是获得关于所有男性的统计资料，并且分别对所有女性进行统计，那么创build一个值得值得。 找出你的查询模式将是什么，并访问哪个参数最窄的search空间，这是你最好的索引。
还要考虑你所做的索引types – B树对于大多数事情来说都是好的，并且允许范围查询，但是哈希索引可以让你直接指向（但不允许范围）。 其他types的指标有其他优点和缺点。
祝你好运！
这一切都取决于你期望询问表格的问题。 如果您要求X列中具有特定值的所有行，则如果索引不能使用，则必须执行全表扫描。
索引将是有用的，如果：
- 一列或多列具有高度的唯一性
- 您经常需要查找列的某个值或某个值的范围。
在下列情况下，它们不会有用：
- 您正在select表格中大量的行（> 10-20％）
- 额外的空间使用是一个问题
- 您想要最大化插入性能。 表中的每个索引都会降低插入和更新性能，因为每次数据更改时都必须更新它们。
主键列通常对索引非常有用，因为它们是唯一的，通常用于查找行。
这真的取决于你的查询。 例如，如果你几乎只写一个表，那么最好不要有任何索引，他们只是减慢写入，永远不会被使用。 您正在使用的任何列与另一个表join是索引的一个很好的候选人。
另外，请阅读关于Missing Indexesfunction。 它监视对数据库使用的实际查询，并可以告诉你哪些索引可以提高性能。
GUID列不是索引的最佳候选。 索引最适合于具有数据types的列，可以给出一些有意义的顺序，即sorting（整数，date等）。
如果一列中的数据一般都在增加，那并不重要。 如果在列上创build索引，索引将创build它自己的数据结构，只需引用表中的实际项目，而不必关心存储顺序（非聚集索引）。 然后，例如，可以在索引数据结构上执行二分search以提供快速检索。
也可以创build一个“聚集索引”来重新sorting数据。 但是，每个表只能有一个，而您可以有多个非聚簇索引。
任何将经常用于从表中提取数据的列都应该被索引。
这包括：外键 –
select * from tblOrder where status_id=:v_outstanding
描述性领域 –
select * from tblCust where Surname like "O'Brian%"
这些列不需要是唯一的。 实际上，在searchexception时，您可以从二进制索引中获得非常好的性能。
select * from tblOrder where paidYN='N'
一般来说（我不使用mssql，所以不能特别注释），主键做好索引。 它们是独一无二的，必须具有指定的价值。 （另外，主键可以创build如此好的索引，以便自动创build索引。）
索引实际上是已经sorting的列的副本，以允许二进制search（这比线性search快得多）。 数据库系统可能会使用各种技巧来加速search，特别是在数据比简单数字更复杂的情况下。
我的build议是最初不要使用任何索引，并分析您的查询。 如果特定的查询（例如，按姓氏search人员）经常运行，请尝试再次在相关属性和configuration文件上创build索引。 如果查询速度明显加快，插入和更新的速度可以忽略不计，请保持索引。
（道歉，如果我重复在你的其他问题中提到的东西，我以前没有遇到过。）
您的主键应始终是一个索引。 （事实上，如果它不是由MS SQL自动索引的话，我会感到惊讶）。您还应该频繁地为SELECT或ORDER索引列; 他们的目的是快速查找单个值和更快的sorting。
索引too列的唯一真正危险是减慢对大表中行的更改，因为索引也都需要更新。 如果您不确定要索引什么，只需记下最慢的查询，查看最常用的列，然后对其进行索引。 然后看看他们有多快。
由于多种原因，以升序或降序排列的数字数据types是好的索引。 首先，数字通常比string（varchar，char，nvarchar等）更快。 其次，如果您的值没有sorting，则可能需要对行和/或页面进行洗牌以更新您的索引。 这是额外的开销。
如果您使用的是SQL Server 2005并使用uniqueidentifiers（guid），并且不需要它们具有随机性质，请查看顺序uniqueidentifiertypes。
最后，如果您正在讨论聚簇索引，那么您正在讨论这种物理数据。 如果你有一个string作为你的聚集索引，那可能会变得很难看。
如果您使用的是GUID，它应该会更快。 假设你有logging
- 100
- 200
- 3000
- ….
如果你有一个索引（二进制search，你可以在O（lg n）时间find你正在查找的logging的物理位置，而不是按顺序searchO（n）时间，这是因为你不知道你有什么logging在你的桌子。
ol的经验法则是在WHERE，ORDER BY和GROUP BY子句中使用很多的列，或者经常用于连接的任何列。 请记住我指的是索引，而不是主键
不要给出“vanilla-ish”的答案，但这取决于你如何访问数据
最佳索引取决于表格的内容以及您正在尝试完成的内容。
举一个例子，成员数据库的成员社会安全Numnber的主键。 我们selectSS是因为应用程序以这种方式向个人反馈，但是您也想要创build一个会使用成员名和姓的search函数。 那么我会build议在这两个领域创build一个索引。
你应该先找出你将要查询的数据，然后确定你需要索引哪些数据。
