輕松精通數據庫管理之道——運維巡檢之三（結構設計）

前言

　　做好日常巡檢是數據庫管理和維護的重要步驟，而且需要對每次巡檢日期、結果進行登記，同時可能需要出一份巡檢報告。

　　本系列旨在解決一些常見的困擾：

• 不知道巡檢哪些東西

• 不知道怎么樣便捷體檢

• 機器太多體檢麻煩

• 生成報告困難，無法直觀呈現結果

　　前面兩篇對服務器軟硬件配置、數據庫概況進行了巡檢，下面我們要對數據庫的一些結構設計進行檢查，這些檢查主要針對系統開發初期一些不優化的結構設計或在系統不斷有新功能增加或運維變動而產生的結構變化。

物理結構概覽

　　在【檢查項】-【全部】中查看每個數據庫的信息，當數據庫結構未通過常規檢查，平臺會提示出警告。

　　注：檢查信息主要包含不規范的表、缺失索引、無索引外鍵、沒有使用的索引、重復索引、老化的索引。

不規范的表

　　在【數據庫】-【不規范的表】中檢查系統中表是否存在有不規范設計。這些不規范設計主要包含無聚集索引，使用舊數據類型，聚集索引的列是隨機增長的（GUID，uniqueidentifier類型）

　　注:

　　1.微軟建議在表中都建議有聚集索引。聚集索引除了可以提高查詢性能之外，還可以按需重新生成或重新組織來控制表碎片。

　　2.在 Microsoft SQL Server 的未來版本中將刪除 ntext、text 和 p_w_picpath 數據類型。 請避免在新開發工作中使用這些數據類型，并考慮修改當前使用這些數據類型的應用程序。 請改用 nvarchar(max)、varchar(max) 和 varbinary(max)。

　　3.聚集索引本身是要排序的，而GUID（uniqueidentifier類型）這樣插入數據時導致過多的頁拆分。

缺失索引

　　（圖略）

　　數據庫設計中索引是性能的一大關鍵，當數據庫缺失大量索引，那么也必然導致數據庫的性能很差。

無索引外鍵

　　（圖略）

• 對主表數據操作時（如刪除），需要到外鍵表中查找校驗，如果缺少外鍵索引可能導致全表掃描，嚴重影響性能。

• 當在查詢中組合相關表中的數據時，經常在聯接條件中使用外鍵列，方法是將一個表的 FOREIGN KEY 約束中的列與另一個表中的主鍵列或唯一鍵列匹配。索引使 數據庫引擎可以在外鍵表中快速查找相關數據，提升性能。

沒有使用的索引

　　（圖略）

　　隨著開發和優化的進行，很多人會對數據庫進行索引的創建操作，很多時候創建了一個較優的聯合索引或者覆蓋索引，會讓原本單列的索引失去使用的場景，這部分索引會出現在，長時間未使用的索引中，建議刪除。

重復索引

　　（圖略）

　　 隨著開發和優化的進行，很多人會對數據庫進行索引的創建操作，那么頁難免會產生一些功能相近或相同的索引，索引本身也是有維護成本，在更新、插入、刪除時會有一定的開銷，那么重復的索引只會增加這部分維護開銷。

老化的索引

　　（圖略）

　　索引維護是配置常規維護任務之一，隨著數據的不斷寫入和變更，會產生大量的索引碎片，缺少維護任務的索引，無法及時重新組織索引數據，導致索引低效，甚至失效。

程序設計結構概覽

　　1.在【檢查項】-【結構設計】中查看會話信息和執行計劃，當設計結構未通過常規檢查，平臺會提示出警告。

　　注：檢查信息主要會話隔離級別、是否存在帶有事務的長時間會話、執行計劃中是否存在隱式轉換。

 會話信息

　　1.在【會話】-【空閑會話】中查看會話信息。

　　注：主要關注，長時間未關閉會話和長時間未關閉并帶有事務的會話。長時間帶有事務的會話可能是因為程序連接泄露導致，長時間帶有事務會阻塞其他會話的正常進行，造成系統卡死等嚴重性能問題。

　　2.在【會話】-【概覽】頁中查看會話詳細信息，主要關注事務隔離級別。

　　事務隔離級別簡述：事務隔離級別主要控制查詢（共享鎖），隔離級別越高并發能力就越差。（詳細信息請參見：平臺技術資料，最佳配置）

　　如果在程序中發現大量REPEATABLE_READ（可重復讀）或SERIALIZABLE（可序列化），請檢查程序是否有必要使用高級別的隔離級別，而導致阻塞等待增加，數據庫并發能力下降。

　　注：如果在系統中存在大量高級別的事務級別，請確認是否需要高的隔離級別而犧牲并發能力。

隱式轉換

　　存在隱式轉換的執行計劃：語句存在隱式轉換導致性能消耗，或不能使用索引。

　　注：隱式轉換常發生在表設計的字段類型（varchar）優先級別低于程序傳遞的參數類型（nvarchar）

　　在【執行計劃】-【隱式轉換】頁中查看具體信息。

總結

　　整個程序和數據庫是否穩定、高效和結構設計的好壞密不可分，在巡檢過程中，結構設計時比較重要的一部分。很多時候運維人員和設計人員、開發人員溝通不暢、專業技能有差距，所以結構設計常常出現問題。