小桌子上没有索引？
“我们应该忘记小效率，大约97％的时间：过早优化是万恶之源。” （唐纳德克努特）。 我的SQL表不可能每行包含几千行（这些都是大的！）。 SQL Server数据库引擎优化顾问会将数据量视为不相关。 所以我甚至不应该考虑在这些表上放置明确的索引。 正确？
索引的价值在于超速读取。 例如，如果您基于日期列中的日期范围执行大量SELECT操作，则在该列上放置索引是有意义的。 当然，一般情况下，您可以在任何要加入的列上添加索引，并加上任何显着的频率。 效率增益也与您的典型记录集的大小与记录数量的比率有关（即抓取20/2000记录比索引获得的好处多于抓取90/100记录的比例）。 在无索引列上进行查找本质上是一种线性搜索。
索引的成本来自写入，因为每个INSERT还需要对每个列索引进行内部插入。
所以，答案完全取决于你的应用程序 - 如果它像一个动态网站，其中读取次数可以是写入次数的100倍或1000倍，并且您正在频繁进行基于数据列的不同查找，索引可能是有益的。 但是，如果写入次数超过读取次数，那么您的调整应该专注于加速这些查询。
只需很少的时间就可以在JOIN / WHERE列上标识和测试少数应用程序的最常见操作，这些操作有或没有索引，我建议您这样做。 监控您的产品应用程序并识别最昂贵且最常见的查询也很明智，并将优化工作集中在这两组查询（这可能意味着索引或完全不同的内容的交集），比如为内存分配更多或更少内存查询或加入缓存）。
Knuth的智慧词不适用于创建（或不创建索引），因为通过添加索引，您不会直接优化任何内容：您正在提供DBMS优化器可用于优化某些查询的索引。 事实上，你最好争辩说，决定不索引一个小表是不成熟的优化，因为通过这样做你可以限制DBMS优化器的选项！
不同的DBMS根据包括表格大小在内的各种因素选择是否索引列有不同的指导原则，这些都应该加以考虑。
什么是数据库过早优化的一个例子：在任何基准测试表明规范化数据库实际上存在任何性能问题之前，“对性能进行非规范化”。
主键列将针对唯一约束进行索引。 我仍然会索引所有外键列。 优化器可以选择忽略您的索引，如果它是不相关的。
如果您只有一点点数据，那么插入/更新的额外成本也不应该太大。
链接地址: http://www.djcxy.com/p/39621.html