數據庫設計

淺談ORM

我是搞C#的菜鳥(別噴)，只接觸過EF和SqlSugar,正在作的項目用到的就是國產的SqlSugar，我的感受寫法還能夠。如今的開發基本上不多還有寫原生sql的了，由於ORM框架不只能提升開發效率，並且還能支持各類數據庫，避免了原生sql在更換數據庫時的尷尬。可是說白了ORM框架最終也是將object轉換成sql語句，不過感受他應該不會給你優化sql吧。當遇到一些複雜查詢的時候，好比多個表關聯、各類子查詢混在一塊兒的時候，框架就顯得有點乏力，感受很死板。

在程序方面，就拿C#來講吧，當查詢少許數據時，ORM框架確定是沒問題，方便高效。若是操做的數據量過大，那確定會有一些弊端，相對於ADO來講仍是顯得比較死板，沒有原生sql靈活，可以適應各類複雜多變的場景。在查詢時要合理利用內存，該緩存的緩存，不要把全部的數據讀到內存再作業務處理，而應該是動態的邊讀邊處理。

總而言之，言而總之，這是我在項目中使用ORM框架時的一點理解。不過如今作的項目通常不可能在去拼寫sql了，可是我仍是以爲仍是應該瞭解一些sql方面的優化。

1、表設計

一、在設計字段類型時，若是某個字段只包含數字，儘可能就設計爲數值類型，不要設計成字符類型，不然會影響查詢和鏈接的性能。

二、儘可能使用varchar或nvarchar代替char和nchar，由於varchar和nvarchar類型長，存儲空間小，能夠節省存儲空間，並且對於查詢來講，在一個存儲空間相對較小的字段內搜索效率要高一些。

三、在數據量不是很大，使用觸發器或自定義函數時，最好是使用表變量，若是是數據量較大可使用臨時表。由於臨時表是利用了硬盤，而表變量是佔用了內存，所以小數據量固然是內存中的表變量更快。並且在存儲過程當中，使用表變量與使用臨時表相比，減小了存儲過程的從新編譯量；若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。

2、索引

一、在查詢時，爲了不全表掃描，應該首先應考慮在 where 及 order by 涉及的列上創建索引。

二、不是全部的索引都是有用的，當索引列有大量數據重複時，查詢可能不會去利用索引，也就提升不了查詢效率。

三、索引並非越多越好，索引在提升查詢效率的同時也下降了插入(insert)和更新(update)的效率，因此在建索引時要慎重考慮，不要放在常常更新的字段上，一張表的索引最好不要超過6個。

3、SQL語句查詢

一、在程序中最好是不要使用select * from t；select count() from t，用具體的字段名代替「」，這樣能夠減小數據負擔。若是是多表關聯查詢，不一樣的表存在相同名稱的字段，也會形成混淆。但若是是在後臺數據庫作臨時查詢，特別是對錶字段不熟悉的時候，用select * 就比較方便了。

二、用exists和not exists代替in和not in，由於in 是把外表和內表做hash 鏈接，而exists是對外表做loop循環，每次loop循環再對內表進行查詢，並且IN不對NULL進行處理，exists會對NULL值進行處理。

三、查詢時，在where字句中使用!=、<>、or、in、not in、like以及對字段進行表達式操做或函數操做時，都是進行全表掃描，雖然有些時候沒辦法避免，可是能換其餘方式的，最好不要作全表掃描。

四、不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。

五、後臺儘可能不要向前臺返回大數據量，若是數據量過大，更應該注意sql優化，不要返回一些不須要的列，或者也該考慮考慮需求是否合理了。並且儘可能避免大事務操做，提升系統的併發能力。