SQL Server 2008 性能问题答案

【问题标题】：SQL Server 2008 Performance QuestionSQL Server 2008 性能问题
【发布时间】：2009-11-24 23:07:21
【问题描述】：

我有一个包含 30 列和大约 340 万条记录的表。 SELECT * FROM [Table]; 花费 8 到 12 分钟返回全部 340 万条结果是否合理？

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

【问题讨论】：

您在什么情况下拨打电话？（ADO.Net、SSMS 等）
1.) 为什么选择“SELECT *”，全选的目的是什么？ 2.) 你有这个表的模式设计吗？（表格布局？）
每行的大小是多少？您的网络连接带宽是多少？是否有其他人同时使用服务器？

标签： sql sql-server performance sql-server-2008

【解决方案1】：

是的，是合理的。对于一个经过微调和优化运行的系统可以在大约 12 分钟内交付 340 万行，这正是预期的结果......

尽管如此，还是有一些地方可以提高性能：

表是否适合缓冲池？ IE。你有足够的内存来存储你的整个数据库吗？如果不是，那么您将针对 IO 访问磁盘。 Page life expectancy 计数器是一个很好的指标。
您的磁盘 I/O 子系统有多快？我们是在谈论 5000 RPM 二手 IDE 驱动器还是 RamSAN-500？ sqliosim 报告的吞吐量是多少？性能计数器怎么样，平均。磁盘队列长度，平均物理磁盘上的磁盘安全/传输？读取与写入是否不同？
表的碎片化程度如何？扫描性能首先受到预读效率的影响，预读大小由 hobt 片段大小决定。或许您需要优化表的 ETL，遵循FastTrack 方法。
发生了任何争用？你测量过锁定等待时间吗？也许快照隔离可以缓解这个问题。
客户端能否及时接收到 340 万行？服务器是否阻止客户端缓冲区可用性？同样，等待统计数据可以表明这一点。

另一个好的起点是遵循Wait and Queues 方法。

【讨论】：

什么？微调和优化运行可以在大约 12 分钟内交付 3.4？你是认真的吗？尝试少于 12 秒。 -1
大声笑，你真的没明白，是吗，基思？
我一定是少了 /sarcasm 标签什么的
是的。如果没有关于系统的最细微信息，我们应该如何猜测性能是否合理？这个结果在上网本上是完全合理的......
@keithwarren7 - 我认为 Remus 试图说明的问题是相对的“这合理吗？”无法对是否存在做出定性决定。因此，在能够提供该性能的系统上，是的，它对于该系统来说是合理的性能。

【解决方案2】：

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

在普通机器上，仅从磁盘读取 3.4Gb 可能需要几分钟（不要忘记这不仅仅是读取，其中显然存在一些 SQL 处理开销。

当然，在现实世界的场景中，您不想检索所有数据...

【讨论】：

【解决方案3】：

开始诊断您的问题的最佳起点是确定您是否有问题。设定一个具体的、可衡量的、以业务为导向的绩效目标，并准确定义您认为返回数据的合理时间。

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

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

【讨论】：

【解决方案4】：

有很多关于磁盘 IO、列大小和其他设置相关的问题可能会被问到。最重要的是，除非您使用的是非常慢的磁盘和慢速网络，否则不会花费 12 分钟。

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

为了更好地排除故障，我会问几件事？有主键吗？是集群的吗？有订单吗？

【讨论】：

【解决方案5】：

评估系统实际运行的查询可能更有趣。 SQL Server 附带的 Profiler 工具可以记录系统正在运行的所有查询。让它在给定的时间段内运行（假设您有大量额外的磁盘空间），它将记录正在运行的查询以及给定的参数。它还会告诉您它们都执行了多长时间。

查看此内容并找出哪些查询占用了您的 CPU 时间，这将帮助您确定在哪里进行性能调整 - 例如，如果查询 A 需要 60 秒运行，并且每天只运行一次，它可能对该特定应用程序进行调整有很大影响，但调整一个查询不会使您的 SQL Server 更快。但如果查询 B 需要 2 秒的时间运行，并且每天运行 4,000 次，那么对其进行调整可能会产生更大的整体影响。

通常添加相关索引并调整“大问题”查询的性能会对性能产生非常严重的积极影响。分析器向您显示的关于这些查询是谁的内容可能会让您感到惊讶。

【讨论】：

【解决方案6】：

与什么相比合理？

行的宽度是多少？
你的 CPU 有多快？
您有多少 RAM？
开始查询时表是否已经在 RAM 中？
您是否通过网络提供结果？如果有，速度有多快？
检索行的客户端有多快？
您的磁盘有多快？
表的碎片化程度如何？
DB 机器是否同时在做其他事情？

【讨论】：

【解决方案7】：

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

除非您的硬件/网络真的很糟糕，否则可以在某处获得性能提升。

【讨论】：

你的行有多大？我可以在大约 3 分钟内恢复单个列，但恢复整个表（大约 4.3GB 的数据）大约需要 12 分钟。