db索引应用程序-最佳实践

我根据最终的查询场景设计索引。对表运行的最常见查询是什么?这将为索引设计提供信息—既可以优化查询性能,又可以最小化插入/更新/删除开销。

例如,简单地在主键上创建聚集索引在理论上可能是有意义的,但可能无法反映实际的查询负载。

通过了解应用程序将启用哪些场景,您可以提前完成很多工作。然后,您还可以在现实世界中进行跟踪,并对其进行分析,以找出缺少索引的地方;例如,SQLServer附带了一些工具来实现这一点,还有第三方工具。我有时使用的一种技术是执行大型跟踪,将跟踪信息上载到表中,并在其中查询不同的SQL语句(基于任何条件。。。e、 g.给我所有关于表xyz…)的更新,然后你可以为这些语句做一个查询计划,看看你的索引有多好,例如,通过适当地查找和寻址表或索引扫描,并通过重新检查查询的执行计划进行验证。

一些注意事项。。。不要随意应用基于痕迹的索引。表上的索引将影响针对该表的所有查询的总体性能。不要认为表或索引扫描(而不是搜索)必然是坏的;在一张十排的桌子上没关系。索引优化是科学和艺术的结合,因此保持它的简单是至关重要的,在小的增量更改后频繁测试是保持理智并能够频繁回滚的好方法,最重要的是,当您有一组更改时,编写它们的脚本,以便您的DBA对将要执行的操作有一个精确的协议,如果需要,可以轻松确定在何处/回滚什么。

如果你知道你大部分时间都在使用哪些字段( where 和 order by 在创建实体时,也可以创建它们。

你可以随时重新访问以后,任何DBA值得他的盐。