开发大型系统（数百个表）时，在创建实体（表）时，是否创建索引（以及更少扩展DB中的其他约束），或者等待系统运行（可能是私有的） Beta）决定把索引放在哪里？
答案 0 :(得分：2)
如果你知道在大多数时候你会使用哪些字段（where和order by子句），你也可以在创建实体时创建它们。
你可以随时重新访问，任何值得他的盐的DBA都会。
答案 1 :(得分：2)
我根据最终的查询场景设计索引。针对该表运行的最常见查询是什么？这应该为索引设计提供信息 - 既可以优化查询性能，又可以最大限度地减少插入/更新/删除开销。
例如，简单地在主键上创建聚簇索引可能在理论世界中有意义，但可能无法反映现实世界的查询负载。
例如：如果您有一个订单商品表，其中0-n个订单商品与父订单相关联，该怎么办？您是否只是创建订单商品ID列，将其指定为主键，然后刻录您的聚集索引，即使在现实世界中，针对此表的查询活动的90％将是“获取订单商品的订单xyz”，这意味着父订单ID上的聚簇索引可能比订单项ID上的“默认”主键聚簇索引更有意义吗？
通过了解应用程序将启用哪些方案，您可以预先做很多事情。然后，您还可以在现实世界中进行跟踪并分析它们以找到缺少索引的位置;例如，SQL Server附带了执行此操作的工具，也有第三方工具。我有时使用的一种技术是做一个大的跟踪，将跟踪信息上传到一个表中，并查询它以查找不同的SQL语句（基于任何标准...例如，给我所有UPDATEs对表xyz ...）然后您可以对这些语句执行查询计划，并查看索引的好坏程度，例如，正确查找和解决表或索引扫描 - 并通过重新检查查询的执行计划进行验证。
一些注意事项......不要根据痕迹不断应用索引。表上的索引将影响针对表的所有查询的整体性能。不要认为表或索引扫描（而不是搜索）必然是坏的;在十排表中没关系。索引优化是科学和艺术的结合，因此保持简单是至关重要的，经常在小增量更改后进行测试是保持理智并能够频繁回滚的好方法，最重要的是，当您进行一组更改时，编写脚本，以便您的DBA具有将要完成的工作的确切协议，并且可以根据需要轻松确定回滚的位置/内容。