数据库索引应用程序 - 最佳实践

Question

在开发大型系统（数百个表）时，是否在创建实体（表）时创建索引（并且减少数据库中的其他约束），或等待系统正在运行（可能是私人测试版）来决定放置索引的位置？

Answer 1

我基于最终查询方案设计索引。对桌面运行最常见的查询是什么？这应该通知索引设计 - 既要优化查询性能，又要尽量减少插入/更新/删除开销。

例如，在主键上简单创建一个聚集索引可能在理论世界中是有意义的，但可能不会反映真实世界的查询负载。

例如：如果您有订单项目表，其中0-n个订单项目与父订单相关联，该怎么办？您是否创建了订单商品ID列，将其指定为主键，然后刻录聚集索引，即使在现实世界中，针对此表的90％的查询活动将是“获取订单xyz的订单商品”，这意味着父订单ID上的聚集索引可能比订单商品ID上的“默认”主键聚集索引更有意义？

您可以通过了解您的应用程序将启用的场景来做很多事情。然后，您还可以在现实世界中进行追踪并分析它们以找到您缺少索引的位置;例如，SQL Server带有工具来执行此操作，也有第三方工具。我使用的一种技术有时也是做一个大的跟踪，将跟踪信息上传到一个表中，并查询它的不同的SQL语句（根据任何标准......例如给我所有UPDATE对表xyz ......），然后您可以为这些语句执行查询计划，并查看您的索引有多好，例如，适当地查找和寻址表或索引扫描 - 然后通过重新检查查询的执行计划进行验证。

一些注意事项...不要根据痕迹应用索引。表中的索引将影响对该表的所有查询的整体性能。不要认为表或索引扫描（而不是查找）肯定是不好的;这在十行表中并不重要。索引优化是科学和艺术的结合，所以保持简单是至关重要的，在小的增量变化之后经常进行测试是保持理智并能够经常回滚的一种好方法，并且最重要的是，当您有一系列变化时，将它们编写出来，这样您的DBA就可以完成一个确切的协议，并且可以根据需要轻松确定回滚的位置/内容。

Answer 2

如果您知道大部分时间将使用哪些字段（where和order by子句），那么在创建实体时您可能会创建它们。

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