“我们应该忘记小效率,比如97%的时间:过早优化是万恶之源。”(Donald Knuth)我的SQL表不太可能包含超过几千行(这些都是大行!)。SQL Server数据库引擎优化顾问认为数据量不相关而不屑一顾。因此,我甚至不应该考虑在这些表上放置显式索引。对,是这样?
发布于 2008-10-31 08:51:52
索引的价值在于提高读取速度。例如,如果您正在根据日期列中的日期范围进行大量选择,那么将索引放在该列上是有意义的。当然,通常情况下,您可以在任何要使用JOINing的列上添加索引,频率很高。效率增益还与典型记录集的大小与记录数量的比率有关(即,抓取20/2000记录比抓取90/100记录从索引中获益更多)。对未编制索引的列的查找本质上是线性搜索。
索引的开销来自写操作,因为每次插入还需要对每个列索引进行内部插入。
因此,答案完全取决于您的应用程序--如果它是一个动态网站,其中读取的数量可以是写入的100倍或1000倍,并且您正在基于数据列进行频繁的、不同的查找,那么索引很可能是有益的。但是,如果写入的数量远远超过读取的数量,那么您的调优应该专注于提高这些查询的速度。
在连接/WHERE列上使用和不使用索引的情况下,只需很短的时间就可以识别和测试几个应用程序中最频繁的操作,我建议您这样做。监视您的生产应用程序并确定最昂贵、最频繁的查询,并将优化工作集中在这两组查询的交集上(这可能意味着索引或完全不同的东西,如为查询或连接缓存分配或多或少的内存)也是明智的做法。
发布于 2008-10-31 13:14:41
Knuth的名言不适用于索引的创建(或不创建),因为通过添加索引,您是在而不是直接优化任何东西:您正在提供一个索引,DBMS优化器可以使用该索引来优化某些查询。实际上,您可以更好地争辩说,决定不索引小表是过早的优化,因为这样做会限制DBMS优化器的选择!
不同的DBMS将根据包括表大小在内的各种因素来选择是否对列进行索引时会有不同的准则,应该考虑这些准则。
What is一个数据库过早优化的例子:在任何基准测试之前,“去正规化的性能”已经表明规范化的数据库实际上存在任何性能问题。
发布于 2008-10-31 08:46:03
将为unique约束为主键列编制索引。我仍然会为所有的外键列建立索引。如果您的索引不相关,优化器可以选择忽略它。
如果您只有很少的数据,那么插入/更新的额外开销也不会很大。
https://stackoverflow.com/questions/252865
复制相似问题