這開始爲this question，但現在看起來更合適，因爲我意識到這是一個DTU相關問題。簡單選擇計數（id）使用100％的Azure SQL DTUs
基本上，運行：
select count(id) from mytable
編輯：添加一個條款似乎不能幫助。
正在運行8到30分鐘之間（而在SQL Server的本地副本相同的查詢需要大約4 秒）。
下面是我運行此查詢時Azure門戶中的MONITOR選項卡的屏幕截圖。注意我在沒有觸及數據庫大約一週後才做了此事，而Azure報告我僅使用了我的DTU的1％。
一對夫婦的多餘的東西：
我欣賞它可能只是我的理解有限，但如果有人能澄清，如果這是真的預期的行爲（即簡單的計數這麼長時間運行，並刷爆我的DTU），這將是大加讚賞。
SELECT COUNT
應執行聚集索引掃描（如果可用）和它的最新版本。 Azure SQL應自動更新統計信息，但如果它們完全過時，則不會自動重建索引。
如果在該表上有很多INSERT/UPDATE/DELETE流量我建議每隔一段時間手動重建索引。
http://blogs.msdn.com/b/dilkushp/archive/2013/07/28/fragmentation-in-sql-azure.aspx
和SO張貼更多信息
謝謝，我一直在重建索引，我想我在使用鏈接到的MSDN文章中的SQL。此表似乎有一個0.2％碎片的CLUSTERED INDEX。 所以據我可以告訴這不是問題。 – chrisb 2014-10-07 08:35:28
@chrisb您正在使用一個人爲設計的例子，保證會導致昂貴的讀取（IO方面）。它不代表真正的疑問。如果你甚至在'WHERE'子句中使用單個索引字段，性能將會快得多 – 2014-10-07 08:43:22
@chrisb我認爲這是我們需要查看統計和執行計劃的地方。以下是如何打開它們的基本指南：http://www.solidq.com/tuning-sql-azure-databases-part-1/ – b0rg 2014-10-07 08:45:22
從您previous question查詢統計數據，我們可以看到：
300ms CPU time
8000 physical reads
8:30大約是500秒。我們當然不受CPU限制。 500ms以上的300ms CPU幾乎沒有利用率。我們每秒獲得16次物理讀取。這遠遠低於任何物理磁盤所能提供的。此外，由於存在物理IO，該表格並未完全緩存。
我會說你被扼殺。每分鐘
934交易事務的一些定義。這大約15轉/秒。也許你每次交易只能達到一個物理IO的限制？！ 15和16是可疑的相似的數字。
通過將實例升級到更高的比例因子來測試該理論。 You might find that SQL Azure Database cannot deliver the performance you want at an acceptable price.
您還應該發現，反覆掃描的一半導致快速查詢，因爲分配的緩衝池似乎適合大部分表（不是全部）。
感謝您的分析。我沒有時間來驗證這一點（如果/當我這樣做，我會標記它是正確的），但我認爲你可能就在這裏 - 我只是感到驚訝，簡單的計數......在哪裏可以佔用這麼多的DTU。我對SQL Server的這方面並不是很有經驗，但是很多人都知道這是一個非常昂貴的操作。 – chrisb 2014-10-27 12:06:10
定義「昂貴」。它需要掃描表格（或其索引）。我認爲這是有道理的，這會產生與表大小成正比的IO。它產生的CPU負載可以忽略不計。 – usr 2014-10-27 15:59:28
我想我的意思是在DTU方面代價昂貴，這實質上就是您使用不同的Azure SQL級別支付的費用。 – chrisb 2014-10-28 19:25:07
我有同樣的問題。與全掃描的表更新的統計數據解決它：
update statistics mytable with fullscan
在原來的問題的答案已經覆蓋會發生什麼。 「簡單」計數實際上是人爲設計的，價格昂貴，必須掃描整個表格。 *不要那樣做*。如果您有一個使用索引字段的WHERE子句，優化器將使用索引查找操作，從而獲得更好的性能。 seek在計算總數之前讀取索引B-Tree以找到匹配的行（即遠小於IO，更好的速度）。如果你使用高選擇性的字段，你將不得不閱讀更少的索引頁面。 – 2014-10-07 08:40:51
只是FTR，'簡單'計數不是人爲的 - 這是我需要做的/沒有各種where子句。 – chrisb 2014-10-30 08:27:29
你有沒有得到一個令人滿意的答案，爲什麼發生這種情況？我看到，在一個擁有5.5億行單個表的127GB數據庫上，S2（50 DTU）的功能與此相同，count（1）接近一個小時。 – 2017-06-02 21:02:47