2010-05-13 33 views

回答

1

经验法则是,如果一个表将包含超过2500万条记录,则应考虑表(和索引)分区,但此功能仅在SQL Server企业版(以及相应的开发人员版)中可用, 。

8

既然你没有说明数据库的目的,或要求,这里有一些一般的东西,没有特定的顺序:在每张桌子上

  1. 小聚簇索引。考虑将它作为每张桌上的主键。这将非常有效,并节省主表和相关表中的空间。
  2. 适当的非聚集索引(覆盖索引如果可能的话)
  3. 一致的命名上的所有数据库对象
  4. 参照完整性
  5. 规范化的表更容易维护
  6. 适当的分区(表和索引),如果你有SQL Server的企业版
  7. 如果您要在数据库中允许直接数据操作,请在表上适当检查约束。
  8. 决定您的业务规则将驻留在哪里,并且不会偏离该位置。在大多数情况下,它们不属于数据库。
  9. 在您使用频繁的查询(至少)上运行查询分析器并查找表扫描。这会杀死性能。
  10. 准备好应对死锁。有了这个规模的数据库,特别是如果会有大量的写作,死锁可能是一个问题。
  11. 充分利用视图来隐藏查询连接复杂性和潜在的查询优化以及灵活的安全实现。
  12. 考虑使用模式来更好地组织数据和灵活的安全实施。
  13. 熟悉Profiler。使用这种大小的数据库,您将花费一些时间来尝试确定查询瓶颈。 Profiler可以帮助你在这里。
+0

如果您的硬件尺寸适当并且配置正确,并且您已涵盖大部分查询工作负载的NC索引,则死锁应该很少见。 – 2010-05-14 01:06:05