小桌子上没有索引？

"我们应该忘记小的效率,比如大约97%的时间:过早的优化是所有邪恶的根源." (唐纳德克努特)我的SQL表不太可能包含超过几千行(并且那些是大的!).SQL Server数据库引擎优化顾问将数据量视为无关紧要.所以我甚至不应该考虑在这些表上放置显式索引.正确？

索引的价值在于超速读取.例如,如果您根据日期列中的一系列日期执行大量SELECT,则在该列上放置索引是有意义的.当然,通常您可以在任何重要频率上加入任何列上的索引.效率增益还与典型记录集的大小与记录数量的比率有关(即,从索引中获取20/2000记录的好处多于获取90/100记录的好处).对未索引列的查找本质上是线性搜索.

索引的成本来自写入,因为每个INSERT还需要对每个列索引进行内部插入.

因此,答案完全取决于您的应用程序 - 如果它类似于动态网站,其中读取的数量可以是写入的100倍或1000倍,并且您基于数据列进行频繁,不同的查找,索引可能是有益的.但是如果写入数量大大超过读取次数,那么您的调优应该集中在加速这些查询.

在JOIN/WHERE列上使用和不使用索引来识别和评估少数应用程序最常用的操作只需要很少的时间,我建议你这样做.监控生产应用程序并确定最昂贵,最常见的查询,并将优化工作集中在这两组查询的交集上(这可能意味着索引或完全不同的内容,例如分配更多或更少的内存,这也很聪明)查询或加入缓存).

Knuth的明智之词不适用于索引的创建(或不创建),因为通过添加索引,您不会直接优化任何内容:您提供的索引可由 DBMS优化器用于优化某些查询.实际上,您可以更好地争辩说决定不对小表进行索引是过早优化,因为这样做会限制DBMS优化器的选项!

不同的DBMS将根据包括表大小在内的各种因素选择是否对列进行索引,从而有不同的指导原则,应该考虑这些因素.

什么是数据库中的过早优化的示例:在任何基准测试之前"对性能进行非规范化"表明规范化数据库实际上存在任何性能问题.

将为唯一约束索引主键列.我仍然会索引所有外键列.如果索引不相关,优化器可以选择忽略您的索引.

如果您只有一点数据,那么插入/更新的额外成本也不应该很大.

这取决于.表是参考表吗？

有一千行的表没有索引,结果表扫描可以区分一个相当简单的操作,将用户延迟5分钟而不是5秒.我已经看到了这个问题,使用的是SQL Server以外的DBMS.

通常,如果表是参考表,则对其进行更新将相对较少.这意味着更新索引的性能损失也相对较少.如果优化程序通过索引,则优化程序的性能损失可以忽略不计.存储索引所需的空间也可以忽略不计.

如果声明主键,则应该获得该键的自动索引.自动索引几乎总能让你足够好以证明其成本合理.留在那里.如果创建没有主键的引用表,则设计方法中还存在其他问题.

如果您对主键以外的某些列进行频繁搜索或频繁连接,则额外的索引可能会为自己付费.除非是问题,否则不要解决这个问题.

这是一般的经验法则:使用DBMS的默认行为,除非您找到不这样做的理由.对您而言,任何其他事情都是过早关注优化的问题.

我建议您遵循有关索引的通常规则，这大约意味着“在查询中使用的那些列上创建索引”。

对于这么小的数据库，这听起来似乎不必要。正如其他人已经说过的：只要您的数据库保持与您描述的一样小，无论如何查询都将足够快，并且实际上并不需要索引。它们甚至可以减慢插入和更新的速度，但是除非您在那里有非常具体的要求，否则对于如此小的数据库而言，这无关紧要。

但是，如果数据库增长了（有时会倾向于哪些数据库），则不必记住向那时可能已经忘记的旧数据库添加索引。也许它甚至已经安装在您的客户那里，您无法对其进行修改！

我想我想说的是：索引应该是数据库设计中很自然的部分，因为缺少索引即是优化，还是过早的优化。