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

低调奢华有内涵

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