处理大型数据库

Question

我已经在一个网络项目(asp.net)工作了大约六个月.最终产品即将投入使用.该项目使用SQL Server作为数据库.我们已经做了性能测试与一些大容量的数据,结果表明,当数据过大,性能会下降,如2万行(超时问题,延迟反应变量等).起初我们使用完全normailized数据库,但现在我们把它归部分由于性能问题(以减少联接).首先,这是正确的决定吗？另外,当数据量变得非常大时,可能的解决方案是什么？客户未来会增加多少？

我想进一步补充:

• 200万行是实体表,解析关系的表有更大的行.
• 数据+否时性能下降.用户增加
• 在识别频繁使用的查询之后进行非规范化.
• 我们还使用了大量的xml列和xquery.这可能是原因吗？
• 有点偏离主题,我的项目中的一些人说动态SQL查询比存储过程方法更快.他们已经做了某种性能测试来证明他们的观点.我认为情况恰恰相反.一些使用频繁的查询是动态创建的,因为大多数其他查询都封装在存储过程中.

Answer 1

在方案中,几百万行不是特别大的数据库.

假设我们正在谈论OLTP数据库,在没有首先确定瓶颈的根本原因的情况下进行非规范化是一个非常非常糟糕的主意.

您需要做的第一件事是在有代表性的时间段内分析您的查询工作负载,以确定大部分工作的完成位置(例如,如果您使用的是SQL Server,则使用SQL事件探查器).查看查询执行的逻辑读取次数乘以执行次数.一旦确定了十大性能最差的查询,就需要详细检查查询执行计划.

我会在这里出去(因为通常是这样),但如果你的问题不是,我会感到惊讶

1. 对于代价高昂的查询,缺少"正确"的索引索引
2. 配置不当或在指定的磁盘子系统下

此SO答案描述了如何配置以查找工作负载中性能最差的查询.

Answer 2

正如那句老话"正常化直到它受伤,反正常直到它起作用".

我喜欢这个!这通常是不能再被接受的事情.我可以想象,回到DBASEIII有时候,你不能一次打开超过4个表(除非改变你的一些AUTOEXEC.BAT参数并重新启动你的计算机,啊!),对非规范化有一些兴趣.

但是现在我看到这个解决方案类似于一个等待海啸给他的草坪浇水的园丁.请使用可用的喷壶(SQL分析器).

并且不要忘记,每当您对数据库的一部分进行非规范化处理时,随着代码中的错误风险的增加,您进一步调整数据库的能力会降低,从而使整个系统的可持续性越来越低.

Answer 3

200万行通常不是超大型数据库,具体取决于您存储的信息类型.通常,当性能下降时,您应该验证索引策略.SQL Server数据库引擎优化顾问可能会对此有所帮助.