如何确定何时在表列上使用索引？

低调奢华有内涵

索引什么时候应该用在表上？
: L1 H2 X7 Q  W[ol]几行索引有意义吗？
如果我的表有恒定的行，只需编辑列(不是’where’在句子中)，即使表只有15行左右，索引还是有意义的？编辑:在这种情况下，非索引选择/读取能否比索引读取更有效？[/ol]编辑：现在我在用它firebird 2.但大多数时候时间都在用，SQL Server 2005/2008。
                                                               
    解决方案:                                                               
                                                                通常，我的索引策略是这样的(我现在只用)SQL Server-根据需要适应自己的数据库系统):
选择一个 好的    群集密钥-不是GUID，不是VARCHAR(250)-或类似的东西- 好的    群密钥是 狭窄、唯一、稳定、不断增长    -像a这样的东西INT IDENTITY完美。使它成为集群的主键->为您提供表上的第一个索引
对于任何用作另一个表的外键列，请添加索引。它可以是单列索引或复合索引，无论哪种情况最适合您。重要的是，将外键列作为索引 第一    列(如果使用复合索引)-否则，JOIN‘s或者检查参考完整性的好处对您的系统不可用
仅此而已。
然后：操作系统-观察并测量-建立基线。应用程序够快吗？如果是的话->完成后，请回家享受业余时间。
2 L! K7 C9 f& b( i3 W% N如果没有，请执行以下操作：开始收集相关应用程序运行速度不够快的数据和说明。看看，比如SQL Server中的DMV等等，他们告诉你性能最差的查询，或者
/ X7 \! P# B# G3 [$ @( Q' N; D缺少索引DMV    。分析这些。看看有什么可以改进。一次    再次添加 一个索引    :观察、测量和比较基准。
/ k. }9 @6 u8 C+ W+ H若有改进->保留这个索引，那么这个测量标准就是你的新基准。冲洗并重复，直到你(和你的用户)对应用程序的性能感到满意( 然后    回家享受您的假期）。
与没有索引相比，SQL Server过度索引可能会 更糟    。不要用太多的索引开始。！仅建立 良好的
: z& K, p9 ~; c) [1 N聚集PK与外键非聚集索引，然后观察、测量、优化和重复循环。