數據庫信息管理系統的邏輯架構與功能設計探析

胡勁

關鍵詞：信息管理系統；數據庫；邏輯架構；功能設計；調優

0 引言

通過對信息管理系統數據庫產生瓶頸的原因進行反復研究分析，主要存在不同量級的數據優化的思路不同，數據的量級隨著時間的推移而提高。大部分系統分析師一般只對遇到的當前量級數據逐步提出優化方案，例如：1萬級無須優化、10萬級排查數據結構的合理性、100 萬級建立合理的索引[1]。這種優化思路形成了反復對性能修復補丁，并沒有一次性解決問題，每個量級的數據性能修復補丁變得更加艱難。

1 基于不同量級數據優化的改進

為了確保數據庫結構的統一原則，在邏輯設計階段表與表之間經常會設計過多的關聯，盡可能地減少數據冗余。但在實際應用中，雖然數據冗余低會使數據的完整性得到保證，提高了數據吞吐率，能夠清晰地表述出數據屬性之間的關系，但當數據庫足夠龐大的時候，多表之間關聯頻繁會降低查詢性能，加大了客戶端程序編程的難度[2]；因此，在物理設計階段，需要根據實際業務需求確定相互存在關聯數據表的最大數據容量和字段屬性的訪問頻次，對此類數據表做頻繁關聯查詢，適當并合理地提高數據冗余，為了提高查詢性能、系統響應速度，合理提高數據冗余是必須的[3]。真實系統的數據庫設計階段應該根據字段類型、查詢語句、算法、索引等多方面進行權衡考慮。

2 實驗對比

2.1 數據表設計的優化

1） 數據庫表命名將業務表與基礎表區分，采用集成基礎庫分布式數據庫設計思路；

2） 字段的類型選擇優先級數字、浮點、字符、文本、二進制，能夠使用基本類型的盡量選擇基本類型，如果強行選擇其他優先級低的數據類型會增加存儲開銷，降低查詢和連接的性能；

3） 謹慎區分char 和nvarchar 兩種字符類型，不可變長字符類型char 查詢速度快，增加硬盤的存儲空間，可變長字符類型nvarchar查詢慢一點，節省硬盤存儲空間；在設計字段的時候可以靈活選擇，針對內容固定長度的數據選擇char，內容長度變化差距很大數據選擇nvarchar；

4） 字段長度設計時，應該根據實際業務需求的最大限度前提下盡可能地簡短，滿足需求即可，這種做法可以大大提高查詢性能，在建立字段索引時也能減少資源的消耗。

2.2 查詢的優化

1） 程序在確保功能實現的基礎上，對數據庫訪問建立的連接次數盡可能地少，并且每次數據庫連接使用結束之后必須關閉連接，做到建立連接和關閉連接一一對應；

2） 盡量避免向用戶端返回過多的數據量，如果數據量較大，應該考慮業務需求分析是否合理，通過查詢條件，盡可能縮小對數據表的訪問行數和結果集，從而降低網絡傳輸過程的壓力；

3） 盡量避免使用select*from Table，一定要用具體的字段名的列表來代替“*”，無須返回業務邏輯中用不上的任何字段；

4） 構建SQL 查詢語句時，盡可能把要求使用的索引放在where條件的首列；

5） where條件語句中的等于（=） 運算不要在左邊進行函數、算術或表達式運算，否則數據庫索引可能會失效；

6） 避免使用游標，因為游標的效率較差，當游標操作的數據大于1萬條時，應該考慮改寫。

2.3 算法的優化

SQL 語句中經常需要融合復雜的算法來解決業務邏輯問題，數據庫越大，算法的瓶頸越容易暴露出來。在此，針對不同的分頁語句在不同的數據量級別進行測試分析，優化實驗結果如下。

2.4 合理建立高效的索引進行優化

SQL Server 數據庫建立索引有兩個目的：確保索引字段的唯一性、實現快速查詢數據的目的。企業級數據庫系統都包括聚集索引和非聚集索引兩種索引，非聚集索引的表的數據是根據Heap 結構存儲的數據，將全部數據添加在表的尾部，聚集索引的表的數據是根據索引字段的順序存儲，并且數據表的聚集索引有唯一性。

聚集索引：數據庫表的數據是根據索引字段的順序存儲，索引項的順序與表中記錄的物理存儲順序必須保持一致；對于聚集索引不需要再有另外單獨的數據頁，因此，每張數據表中最多只能創建唯一的一個聚集索引[4]。

非聚集索引：數據庫表的數據記錄存儲順序與索引字段順序無關，非聚集索引采用葉結點的數據頁和數據行中邏輯指針指向索引字段值。因此，邏輯行數量與數據表行數據量完成保持一致[5]。

1） 建立高效索引的思路；

2） 結合實際情況淺談索引使用過程中的誤區。

理論的目的是應用，應用次數越多，經驗越豐富。

誤區一：主鍵就是聚集索引

通常習慣在每個數據表中建立一個自動增長的TableKey 列或以Gid 為值的列為主鍵，像SQL Server 數據庫系統就會將它默認為聚集索引，類似于這樣的聚集索引并不能完全發揮最大的性能優勢；要想使用聚集索引達到最大性能優勢，應該根據查詢中的條件縮小范圍和避免全表掃描，某種情況下使用TableKey 主鍵作為聚集索引是一種資源浪費[6] 。

在無紙化網絡辦公系統的公文、會議、督辦等模塊中，無論是首頁提示用戶待簽收的公文、會議提醒、督辦提醒，還是用戶進行已辦公文、會議、督辦等查詢操作，只要是按需進行數據查詢都將離不開字段的是“時間”和用戶的“人員ID”。

誤區二：建立索引就一定能夠提高數據查詢的性能與速度

兩條完全相同的SQL 語句：select TableKey from 0T1ab-l2e1 w，h并ere且 時針間對＞同一20個22-da0t1e- 字20段a建nd立 時索間引＜；索20引22區-別一種是對“時間”字段建立非聚集索引，兩種方案是對“時間”字段建立聚集索引，兩種查詢速度有著很大的差距。所以，并不是所有字段上只要建立索引就一定能夠提高查詢性能與速度[7]。

要想建立合適的索引，應該根據數據的分布情況加以分析，例如：無紙化網絡辦公系統公文表中有著百萬級數據量的“時間”字段，有著上千條不同日期的記錄，同一個日期又存在若干條公文記錄，根據建立高效索引的思路得出在此字段上建立聚集索引是最佳的選擇。

誤區三：只要提高數據查詢性能與速度的字段就全部加聚集索引

SQL Server 雖然只能建立一個唯一的聚集索引，但經常會出現同時多個字段都需要建立聚集索引的情況，這時通常可以把他們合并一起建立一個復合索引，也并非所有的字段都適合加入聚集索引，需要根據實際情況權衡選擇。

復合索引查詢性能的主要體現是查詢條件中是否用到索引中的全部列。比如：根據無紙化網絡辦公系統公文中的“人員ID”和“時間”字段，通過分析這兩個字段非常重要，并且基本上都會同時出現在查詢條件當中，那么就可以將它們合并建立一個復合的聚集索引，并且“時間”為起始列、“人員ID”排在后列[8]。

3） 其他事項

只有建立合理的索引才有利于提高數據查詢的性能，如果過多或者不當的建立索引會導致系統產生更嚴重的瓶頸，因為每一個索引都會導致存儲空間的增加和數據庫會做更多復雜的工作，并且產生大量的索引碎片。所以，要想建立一個合理的索引體系，需要融合更多的實戰應用分析，結合調優結果精益求精建立索引，才能使數據庫的性能達到最佳的狀態。

3 結論

綜上所述，通過大型信息管理系統中的數據庫設計和優化進行反復論證，本文針對數據庫設計和優化提出以下幾點思路：1） 數據表中每一個字段的設計都必須非常嚴謹，比如數據類型選擇、長度設計等；2） 查詢語句的優化是SQL效率優化的一個方式，可以通過優化SQL語句來盡量使用已有的索引，避免全表掃描， 從而提高查詢效率；3） 不斷優化復雜的算法來解決數據量大的業務邏輯問題；4） 建立最合理的索引體系可以大大提高系統的性能。