SQL Server 2008性能问题

Question

我有一个包含30列和约340万条记录的表。 SELECT * FROM [Table];需要8到12分钟才能返回所有340万个结果？

如果不是，哪里是开始诊断我的问题的好地方/资源？

Answer 1

这很有可能是SQL服务器正在尽最大努力来获取您要求的数据。 假设至少1K /记录30列并非不合理。 3.4M×1K = 3.4Gb。

从盘面可能需要几分钟的平均机上只是阅读3.4Gb（不要忘了，这不只是读书，显然有它的一些SQL处理开销。

但是，当然在真实的场景中你不想检索所有的数据...

Answer 2

是的，是合理的。对于一个系统，精细调谐和最佳运行可以在约12分钟内提供3.4万行，这正是预期的结果...

无论如何，一些地方寻找提高性能：

• 该表是否适合缓冲池？ IE浏览器。你有足够的RAM来存储你的整个数据库吗？如果不是，那么你会打到磁盘的IO。 Page life expectancy计数器是一个很好的指标。
• 磁盘I/O子系统有多快？我们是在谈论一个5000 RPM的二手IDE驱动器或RamSAN-500吗？ sqliosim报告的吞吐量是多少？性能指标如何，Avg。磁盘队列长度，平均值磁盘秒/物理磁盘上的传输？ Reads vs. Writes不同吗？
• 表格有多碎片？扫描性能首先受到预读效率的影响，预读大小由霍普片段大小决定。也许你需要优化表的ETL，遵循FastTrack方法。
• 任何争用正在进行？你有没有测量锁定等待时间？也许snasphot隔离可以解决问题。
• 客户能够及时收到3.4密耳的行吗？客户端上的服务器块是否可用？再次，等待统计可以表明这一点。

另一个开始的好地方是遵循Wait and Queues方法。

Answer 3

有很多问题可能会被问到与磁盘IO，列的大小和其他设置相关的事情。底线，除非你是一个非常慢的磁盘和慢速网络，它不应该需要12分钟。

首先要看的是执​​行计划。这应该让你了解SQL Server如何处理事物。

夫妇的事情，我会问，以更好地排除故障？有主键吗？它是否聚集？有订单吗？

Answer 4

开始诊断您的问题的最佳位置是确定您是否有任何问题。设定一个具体的，可衡量的，面向业务的绩效目标，并确定您认为合理的返回数据的时间。

如果你的答案是8-12分钟，那么你没有问题，这总是一件好事。

如果你的答案比这还少，那么你现在知道你有问题，问题有多大（如果你说5分钟，那么这可能不是一个很大的问题，如果你说10秒，那么它是一个更大的问题）。在这种情况下，您可能需要开始查看数据库性能计数器，以查看是否存在CPU/IO /内存/网络瓶颈，并查看查询的执行计划以查看是否可以通过索引来改进尽管这对SELECT *来说不太可能）。

Answer 5

评估系统实际运行的查询可能更有意思。 SQL Server附带的Profiler工具可以记录您的系统正在运行的所有查询。让它运行一段时间（假设您有足够的额外磁盘空间），它将记录正在运行的查询以及给定的参数。它还会告诉你他们全部执行了多久。

考虑这一点并确定哪些查询正在使用CPU时间将帮助您找出性能调整的位置 - 例如，如果查询A需要60秒运行并且每天只运行一次，可能会对该特定应用程序产生重大影响，但调整该查询不会让您的SQL Server更快。但是如果查询B每秒运行2秒并且每天运行4000次，那么调整它可能会产生更大的整体影响。

通常，添加相关索引和调整“大罪犯”查询的性能可能会对性能产生非常严重的积极影响。分析器告诉你哪些查询可能会让你大吃一惊。

Answer 6

比较合理吗？

1. 行宽有多宽？
2. 你的CPU速度有多快？
3. 你有多少内存？
4. 当您开始查询时，表是否已经在RAM中？
5. 您是通过网络传递结果吗？如果是这样，它有多快？
6. 检索行的客户端有多快？
7. 你的磁盘有多快？
8. 表格有多碎片？
9. DB机器是否在同一时间做其他事情？

Answer 7

我同意你的观点，我在不到3分钟的时间内从SQL 2008服务器中取回了2000万行数据 - 硬件成本低于SQL许可证。

除非您的硬件/网络真的很糟糕，否则在某个地方会有性能提升。