Question

我发现我们的系统在标称负载下撞击节流墙，例如每个实例每秒120次插入。还有其他并发进程正在运行，我们正在卸载/优化等等。我想知道的是：有没有人对索引的存在对限制的影响程度有任何见解？我在系统的其他地方存在一些性能问题，其中索引的存在会有所帮助，但由于其额外的CPU和I / O负载，我不愿意添加它们！

欢迎任何现实世界的建议。请保持SQL Azure特定。

Answer 1

限制基本上只是CPU，内存和磁盘使用量的上限。因此，指数对限制的影响归结为它对这些资源的影响。所以这真的就像任何其他性能调整场景一样 - 找出你要达到的限制，并确定如何使用更少的限制。

SQL Azure与SQL Server不同，主要是因为您无法访问所有酷DMV。你仍然得到一些，但不是全部。你得到的一个好处是，如果你遇到限制错误，他们应该告诉你你被限制的资源。

根据您的具体情况，以下查询可能会有所帮助。我从Glenn Berry偷了这些，我唯一的贡献是弄清楚它们是在Azure上运行的。他还为SQL性能工作提供了很多很好的建议，尽管他专注于非Azure安装。

--List query plans and stats ordered by last execution time
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
        s.max_elapsed_time, s.max_worker_time,  (s.total_worker_time / s.execution_count) AS AverageExecutionTime,
        s.max_physical_reads, s.max_logical_reads, 
        s.max_logical_writes, s.min_rows, s.max_rows
FROM sys.dm_exec_query_stats as s
      cross apply sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY s.last_execution_time DESC


--List query plans and stats ordered by average execution time
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
        s.max_elapsed_time, s.max_worker_time, (s.total_worker_time / s.execution_count) AS AverageExecutionTime,
        s.max_physical_reads, s.max_logical_reads, 
        s.max_logical_writes, s.min_rows, s.max_rows
FROM sys.dm_exec_query_stats as s
      cross apply sys.dm_exec_sql_text(plan_handle) AS q
ORDER BY [AverageExecutionTime] DESC

--Get 50 most I/O intensive queries
SELECT TOP(50) OBJECT_NAME(qt.objectid) AS [SP Name],
qs.total_logical_writes,
qs.total_logical_reads,
(qs.total_logical_reads + qs.total_logical_writes) /qs.execution_count AS [Avg IO],
SUBSTRING(qt.[text],qs.statement_start_offset/2, 
    (CASE 
        WHEN qs.statement_end_offset = -1 
     THEN LEN(CONVERT(nvarchar(max), qt.[text])) * 2 
        ELSE qs.statement_end_offset 
     END - qs.statement_start_offset)/2) AS [Query Text],
qs.execution_count,
qs.creation_time
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
WHERE qt.[dbid] = DB_ID()
ORDER BY [Avg IO] DESC OPTION (RECOMPILE);

--Get executing requests
SELECT session_id, blocking_session_id, wait_type, last_wait_type, wait_time, total_elapsed_time, cpu_time, logical_reads, reads, writes
FROM sys.dm_exec_requests AS r
ORDER BY wait_time DESC

Answer 2

当涉及到索引时，您当然需要评估查询的开销与性能改进之间的权衡。什么会伤害你最多的是没有使用的索引，因为维护索引的开销属于被限制的类别。

如果你添加一个索引，你能摆脱另一个现已过时的吗？您的查询是否因添加索引而消耗更少的限制资源（I / O，内存，CPU）？

另请注意，CPU不再受到严格限制（如I / O或内存）;查询将执行得更慢，但它们将执行。

最后，我很少看到索引是限制的重要原因，除非在创建索引（或刷新）时。尽管如此，常识在SQL Azure中也适用于SQL Server：创建不太宽的索引，并确保索引减少现有的查询资源消耗。

使用DMV可以帮助您确定整体资源消耗是否在下降。

Answer 3

确保不要将GUID用于具有聚簇索引的PK。

SQL Azure限制 - 索引的影响

3 个答案: