如何对规范化程度很高的数据库系统进行非规范化?

时间:2009-04-27 13:51:02

标签: sql-server-2005 performance caching denormalization

我希望将一些数据库非规范化引入到一个高度规范化的系统中。

我有一大堆数据库,这些数据库已经发展了十多年,而且负载越来越大,所以我希望提高性能,并可能降低某些查询的复杂性。

在存储过程中执行10个连接以完成任何给定任务并不罕见。我被告知超过6个臭。

我应该保持表结构不变并提供一些物化视图或非规范化“缓存”表。

关于最佳实践或推动正确方向的一些建议会有所帮助。

由于

5 个答案:

答案 0 :(得分:11)

你没有说出问题所在。是性能吗?如果是这样,在什么表上?

这真的是导致问题的连接吗?还是存储过程?你不知道(至少,你没有说)。

最佳做法:在尝试解决尚未确诊的问题之前,先弄清楚瓶颈在哪里。


编辑:当我们遇到性能问题时,我想起了工作的时间。非常慢的存储过程,可能需要几分钟才能完成。事实证明,这些sps正在进行完全正常的表更新,但使用游标。对于像update t set c = c + 1 where id = n这样简单的东西。

因此,为了进行更新,我们通过一堆昂贵的更新游标进行游说并执行declare cursor for "select c from t where id = n" for update;然后打开游标,读取和错误检查以及带有读取和错误检查的循环然后select c into @c; @c = c + 1; update t set c = @c where current of cursor;进行每次更新。

原来写这篇文章的人没有意识到我们可以发布更新声明。所以他写了几十个缓慢存储过程。我们甚至不需要摆脱存储的过程(尽管这会让我们获得一些速度,它会改变我们的客户端);我们刚刚摆脱了游标,用更新语句替换它们。性能问题消失了。

答案 1 :(得分:2)

要调查的一些事情

  • 对所有查询运行时间进行基准测试 - 给自己一个与之比较的指标。
  • 调查索引已正确完成。
  • 阅读table partitioning
  • 探索sharding as an option
  • 密切关注你的联接。你总是一起加入同桌吗?如果答案不那么明显,你仍然可以使用视图创建逻辑分区(比如你的非规范化表)。

答案 2 :(得分:1)

尝试严格而明智地编制索引。 尝试使用索引视图。 尝试预编译的存储过程。 如果失败,请记住,非规范化和缓存通常需要大量的同步工作,所以在进行之前你应该仔细查看每个案例。

答案 3 :(得分:0)

我必须同意,10个连接是邪恶的,会杀死你的表现。

很大程度上取决于您的应用程序如何与数据库交互。如果你的代码严格遵守存储过程(没有直接的SQL调用)那么你的生活会更容易。

如果你遇到非规范化的麻烦,我不会添加新的“缓存”表。这只是修补问题。我将继续制定一个完整的计划,使用新的优化模式对数据库进行非规范化。

答案 4 :(得分:0)

我同意以利亚的观点。确保你对即将改变的任何东西进行基准测试。

此外,根据您的设置,索引视图可能是一个选项。