數據庫性能與複製
我正在研究數據庫優化（計劃未來的項目增長）並且需要一些幫助。
目前，每個表都使用 uniqueidentifier 作為 PK（聚集索引），並且我們有很高的索引碎片（99%）。對於新表，我們開始使用 bigint 作為 pk，但當雙向複製階段到來時，我不想做噩夢。
我做了我的研究，uniqueidentifier 不是一個大問題（記憶體除外），問題是該列上的集群索引（http://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-分群鍵/）。
我們可以這樣做來解決我們的碎片問題和任何複製噩夢：
- 將 ROWGUIDCOL 添加到 PK 列
- 在每個表中添加另一個標識列並將該集群索引（不是 pk）移動到該列
這個新的標識列會導致與 bigint PK 相同的複制問題嗎？我知道 SharePoint db 主鍵是 GUID，但我對它的性能不滿意，並且可能安全性在該決定中起到了一定的作用。我們可以通過使用 seq. GUID，但我們不能在應用程序端創建它或使用 SCOPE_IDENTITY() 返回它。OUTPUT inserted.ID hack 會很耗時，因為我們需要重寫完整的應用程序 DAL。
最後，這個問題有什麼有效的解決方案嗎？我們可以在沒有任何複製問題的情況下使用 bigint。
在與我現在工作的不同組織的先前角色中，我們面臨著類似的決定，即 GUID 問題（如鍊接中指出的）是我們的一個因素（寬度和索引碎片的錯誤選擇） - 但我們需要遷移到事務複製（點對點）以允許我們的站點在地理上分開。
在我們的開發環境中，我們將大部分 GUID 轉換為身份列，設置複製以匹配預期的生產系統，並確保身份列在每個節點具有單獨的範圍（根據http://technet.microsoft.com/ en-us/library/ms146907(v=sql.105).aspx - 這也為自動身份範圍管理提供了建議，這可能對您有用）。
到目前為止聽起來不錯？不…
身份列管理起來簡直是一場噩夢，通過我們的開發測試和自動化範圍分離的工作，我們放棄了它們（從未投入生產） - 在我看來，這比它的價值更麻煩 - 我們解決了回到數據庫中已經存在的 GUID，並解決了一些記憶體浪費和索引碎片的已知問題。
對我們來說，這並不是一個有害的解決方案——因為幾乎所有的使用都是讀操作相當低的寫操作——顯然我們有一個維護計劃，試圖盡可能地處理碎片（有一些更新操作- 所以讀取然後寫入，但延遲在門檻值內）。
我的 2 便士是 - 避免使用身份列（除非您已經為它們制定了一個很好的計劃 - 或者您可以添加一個靜態單元（即伺服器 1 總是有一個前面的字母 A1、A2 等。伺服器 2 = B1、B2 等））在複製和測試它的生命時 - 假設您可以設置一個副本開發系統或其他任何東西。當然，這取決於您是否可以忍受 GUID 由於其索引問題而提供的糟糕的讀取訪問權限！
祝你好運。
為什麼不改變分配它們的方式，而不是簡單地避免將 GUID 作為集群鍵呢？您是否使用 NEWID() 來生成您的密鑰？如果是這樣，請使用NEWSEQUENTIALID()，您可能會在碎片化方面做得更好。