非葉級別的碎片是一個問題嗎？

SQL 版本：2017 標準 x64 作業系統：Windows Server 2016 Datacenter (10.0)

我剛剛在 ETL 表上創建了一些最小索引，這些表以前是沒有索引的堆。R 和 W 性能都有所提高。以為我會密切關注索引碎片，所以我正在查看 sys.dm_db_index_physical_stats: in DETAILED 模式，只是為了了解有關該領域的更多資訊。我是一位經驗豐富的 DWH 開發人員而不是 DBA，所以我的問題對於 DBA 來說可能是非常初學者（這裡沒有 DBA，或者他們會處理這個問題）。

我正在查看的索引是一個聚集的唯一索引。該表有 130 萬行。在葉級別 (0) 我看到 0.89% 的碎片：好。在更高的層次上，雖然存在碎片化。索引的級別為 0-3。在 2 級，碎片率為 52%，fragment_count=23，record_count=2781。

這讓我很困惑，尤其是因為我昨天才創建了索引。

1. 非葉級別的碎片是性能問題嗎？
2. 2級怎麼會有這麼多碎片？
3. 在聚集索引中，B 樹中的非葉 (>0) 級別實際儲存什麼？它不能是級別 0 中的行數據：它是指向一組較低索引條目的指針嗎？
4. 如果我對 3 點的看法是正確的，那麼重組/重建 B 樹的上層（例如只有 2781 條記錄的樹）似乎是一項微不足道的工作，而不會接近重組葉級別的繁重工作。但我看不到任何提及這樣做的方法。
5. fragment_count實際上是什麼意思，尤其是在更高級別？文件只說邏輯碎片是“索引葉子頁面中亂序頁面的百分比” 。fragment_count是索引的連續區域的計數，它們在內部是有序的嗎？

1. 不會。非葉子索引頁特別有可能留在記憶體中。原則上，它可能會在第一次發生帶有預讀的索引掃描時稍微減慢預讀（上層用於驅動），但是嗯。有些人認為任何級別的碎片都是正常的事情，如果數據通常已經在記憶體中，或者儲存子系統是否具有低延遲和良好的吞吐量，則無需擔心。
2. 因為 SQL Server 不會竭盡全力避免它。非葉子頁面也可以體驗頁面拆分。在葉子 ( ) 上方填充索引PAD_INDEX是可能的，但很少值得。
3. 聚集索引鍵和任何唯一性。
4. 這沒有實施。
5. 我相信這是對索引該級別的連續區域數量的計數，是的。

引用自：https://dba.stackexchange.com/questions/261181