分區表和索引 - 有什麼缺點？
在談論分區表少於 100 個的表的分區表和索引時，
沒有非對齊索引：
我的意思是：
> > 非對齊索引 > > >
獨立於其對應表分區的索引。
也就是說，索引具有不同的分區方案或被放置在與基表不同的文件組中。
設計非對齊分區索引在以下情況下很有用：
基表尚未分區。
索引鍵是唯一的，它不包含表的分區列。
您希望基表參與與使用不同連接列的更多表的並置連接
除了：
1 - 減慢一些 DBCC 命令
2 - 對除分區列以外的列使用運算符（例如 TOP 或 MAX/MIN）的查詢可能會遇到分區性能降低，因為必須評估所有分區。
3 -
使用分區消除的查詢可能具有與更多分區相當或改進的性能。隨著分區數量的增加，不使用分區消除的查詢可能需要更長的時間來執行。
擴展您的列表，以下是我們在實際生產工作負載中遇到的幾個潛在缺點：
尋找多個分區
擴展不使用分區消除的查詢可能需要更長的時間來執行點，有一個特別受影響的特定模式：單例查找。如果需要訪問所有（甚至一小部分）分區，則此操作將變得慢得多。跳過掃描操作實質上是對每個無法消除的分區進行查找。
假設您有 10 億行表 (
N = 1,000,000,000)，其中行均分為 1,000 個分區 (P = 1,000)。單次查找大致O(log(N)) ~ 30在非分區表中。然而，O(P*log(N/P)) ~ 20,000在這個假設的分區表中，這個相同的查找操作大致變成了。因此，如果需要來自所有分區的數據（或者有時即使不需要，但 SQL 無法根據您的查詢證明這一點），則 seek 現在執行的工作量會增加 500 倍以上。請注意，當您顯式查詢表中的一行（或一小部分行）時，當分區表出現在循環連接的內側時，這可能會出現在更複雜的查詢中。好消息是，SQL Server 在基於成本的優化中考慮到這一點相當不錯，但這通常仍然意味著當循環搜尋到非分區表會更加優化時，您會獲得雜湊連接。
並行查詢執行中的執行緒傾斜
在並行查詢計劃中，執行緒被分配給分區。如果有一個分區比其他分區大得多，則針對該表的查詢可能特別容易受到執行緒傾斜的影響。一個執行緒的行比例可能過高，並且在其他執行緒完成工作後很長時間才開始處理。這種情況也可能發生在非分區表上，但是任何不均勻分佈行的分區函式都特別容易受到攻擊。
有關將執行緒分配到分區的更詳細說明，請參閱分區對象的並行查詢執行策略。例如：
查詢處理器對從分區對像中選擇的查詢使用並行執行策略。作為執行策略的一部分，查詢處理器確定查詢所需的表分區以及分配給每個分區的執行緒比例。在大多數情況下，查詢處理器為每個分區分配相等或幾乎相等數量的執行緒，然後跨分區並行執行查詢。
