SQL Azure节流-索引的影响

我发现我们的系统在额定负载下撞击节流墙，比如说每个实例每秒120次插入。还有其他正在运行的并发进程，我们正在卸载/优化这些进程。我想知道的是：有人对索引的存在对节流的影响程度有什么见解吗？我在系统中的其他地方有一些性能问题，索引的存在会有所帮助，但我不太愿意添加它们，因为它们会增加CPU和I/O负载

---

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

节流基本上只是限制CPU、内存和磁盘使用。因此，索引对节流的影响归结为它对这些资源的影响。因此，这与任何其他性能调优场景都是一样的——找出您达到的极限，并确定如何减少使用

SQLAzure与SQLServer不同，主要是因为您无法访问所有酷的DMV。你仍然可以得到一些，但不是全部。您确实得到的一个好处是，如果您遇到节流错误，它们应该告诉您正在节流的资源

根据您的情况，以下查询可能会有所帮助。我偷了这些，我唯一的贡献就是发现它们运行在Azure上。尽管他专注于非Azure安装，但他也得到了很多关于SQL性能工作的建议

--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

---

当涉及到索引时，您当然需要评估查询的开销与性能改进之间的权衡。对您影响最大的是未使用的索引，因为维护索引的开销属于被限制的类别

如果你添加了一个索引，你能去掉另一个现在已经过时的索引吗？由于添加索引，您的查询是否消耗更少的限制资源（I/O、内存、CPU）

还要注意的是，CPU不再以硬方式进行节流（如I/O或内存）；查询将执行得较慢，但会执行

最后，我很少看到索引是节流的一个重要原因，除非是在创建索引（或刷新）时。然而，常识适用于sqlazure，就像在sqlserver中一样：创建不太宽的索引，并确保索引减少现有的查询资源消耗

---

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

确保不要将guid用于具有聚集索引的PKs

你介意提供更多关于节流墙的信息吗？您提到每个实例每秒插入120次。这是否意味着在多个实例中每秒插入的总次数将超过120次？你的整体表现如何？另外，您使用的计算实例大小是多少？还有：有多少线程正在处理您的插入？如果它是单线程的，插入速率可能会受到插入序列性质的限制。我们正在负载下对系统进行压力测试。此配置不分片。我正在尝试了解单个SQLAzure实例的负载限制。对于前端，此配置有两个额外的购物中心web角色。所有这些都与SQL Server上的节流有关。在这里，web角色实例的大小并不重要，IMO。我们对多达300个并发请求进行了压力测试。现在，我们正在通过缩小表、删除索引/约束、为集群键提供默认值等策略来衡量SQL Azure实例可能会被挤出多少性能。这是一个很好的优化方法，但感谢您的评论。guid是聚集索引中的页面分割噩梦，所以是的。同意。你的答案应该包含这样一个提示，供将来的读者参考。好的，节流问题如何，解决了吗？当节流时，你到底经历了什么？请求返回的时间更长，还是返回错误？好问题。它永远不会解决；这是SQLAzure设计的一部分。我们正在这个平台上构建高扩展，而AZT上没有NoSQL，所以现在我们想看看每个实例能挤出多少能量。120是当前的临界点，但我们可以通过BCP获得更高的水平，所以我们现在正在分析所有的小运动部件。我将在继续时更新。您是否使用瞬态故障处理应用程序块？对于SQLAzure，重试逻辑是必须的。我们已经有了同样的逻辑。EAB将使它更干净。通过添加索引指出节省I/O、内存和CPU的可能性是非常好的。我喜欢提醒大家考虑决定的所有影响。