Azure SQL數據庫中的索引

Question

我有一個Azure SQL數據庫，迄今爲止已證明非常成功。這是大約20個月大，沒有維護...但它處理了很多。某些表有數百萬行，當查詢索引列時，查詢響應時間在使用與之交談的Web應用程序時是可以接受的。

但是，我讀到了有關重建索引的衝突建議。

這傢伙說，有在做沒有意義：http://beyondrelational.com/modules/2/blogs/76/posts/15290/index-fragmentation-in-sql-azure.aspx

這傢伙說，繼續重建： https://alexandrebrisebois.wordpress.com/2013/02/06/dont-forget-about-index-maintenance-on-windows-azure-sql-database/

我已經運行存儲幾千上的一些小表的一些重建索引的語句行。一些碎片會下降大約1/2 ...然後，如果我第二次運行它，它可能會下降約

這些重建運行大約2-10秒，具體取決於表的大小...

然後我跑了有上有大約200萬行的表下面的碎片索引： PK__tmp_ms_x__CDEC17C03A4CDB46 55.2335782060565 PK__tmp_ms_x__CDEC17C03A4CDB46 0 IX_this_is_my_fk_index 15.7538877620014

花了33分鐘。

結果是 PK__tmp_ms_x__CDEC17C03A4CDB46 0.01 PK__tmp_ms_x__CDEC17C03A4CDB46 0 IX_this_is_my_fk_index 0

問題： 查詢速度還沒有真正因爲做上述改變。這是正常的嗎？

鑑於SQL Azure中有很多我無法控制的東西，它是否對重建索引更有意義？

BTW：我不是，也永遠是一個DBA ...只是開發商如果實際使用索引

Answer 1

重建索引會沒關係。如果索引不被用於您正在運行的查詢，那麼您將看不到差異。如果只是輕微使用，如果您運行統計信息，則會看到細微差異。如果它被大量使用，大部分時間你都會看到性能提升。另一件需要注意的問題是，索引碎片有時是不相關的。通常，當我選擇是否重建索引時，我會看看頁數與碎片相結合。如果即時通訊運行一個查詢，我有性能問題，即時通訊使用索引，索引有超過16000頁，並且索引超過50％碎片，不適重建它。如果桌子很小或者我可以使用在線選項，我將繼續並同時重建所有這些選項。

特別針對Azure，我認爲如果您嘗試提高性能，它仍然是一個很好的步驟，因爲它很容易，即使你不能確定結果。無論是否有共享服務，以及是否可以控制硬件層，檢查索引碎片和重建索引都是您可以訪問的東西，那麼爲什麼不使用它呢？

所以我想簡單的回答是肯定的，在某些情況下。

我會建議，而不是手動檢查索引並重建它們，建立一個每晚或每週工作，當您的db最不活躍時運行。讓它遍歷所有表並重建索引。如果你有很多表格，你也可以給它一個設定的運行時間，然後使它成爲「有狀態的」（你可以使用一張表來保留進度信息），以便它記住它停留的地方並在下一次計劃運行時恢復。