淺談ORM

我是搞C#的菜鳥(別噴)，但是編程思想都是想通的。何不如聽一聽我這個C#程序員的編程思考呢？

只接觸過EF和SqlSugar,正在做的項目用到的就是國產的SqlSugar，個人感覺寫法還可以。現在的開發基本上很少還有寫原生sql的了，因為ORM框架不僅能提高開發效率，而且還能支持各種數據庫，避免了原生sql在更換數據庫時的尷尬。但是說白了ORM框架最終也是將object轉換成sql語句，不過感覺他應該不會給你優化sql吧。當遇到一些復雜查詢的時候，比如多個表關聯、各種子查詢混在一起的時候，框架就顯得有點乏力，感覺很死板。

在程序方面，就拿C#來說吧，當查詢少量數據時，ORM框架肯定是沒問題，方便高效。如果操作的數據量過大，那肯定會有一些弊端，相對于ADO來說還是顯得比較死板，沒有原生sql靈活，能夠適應各種復雜多變的場景。在查詢時要合理利用內存，該緩存的緩存，不要把所有的數據讀到內存再做業務處理，而應該是動態的邊讀邊處理。

總而言之，言而總之，這是我在項目中使用ORM框架時的一點理解。不過現在做的項目一般不可能在去拼寫sql了，但是我還是覺得還是應該了解一些sql方面的優化。

一、表設計

1、在設計字段類型時，如果某個字段只包含數字，盡量就設計為數值類型，不要設計成字符類型，否則會影響查詢和連接的性能。

2、盡量使用varchar或nvarchar代替char和nchar，因為varchar和nvarchar類型長，存儲空間小，可以節省存儲空間，而且對于查詢來說，在一個存儲空間相對較小的字段內搜索效率要高一些。

3、在數據量不是很大，使用觸發器或自定義函數時，最好是使用表變量，如果是數據量較大可以使用臨時表。因為臨時表是利用了硬盤，而表變量是占用了內存，因此小數據量當然是內存中的表變量更快。而且在存儲過程中，使用表變量與使用臨時表相比，減少了存儲過程的重新編譯量；如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統表的較長時間鎖定。

二、索引

1、在查詢時，為了避免全表掃描，應該首先應考慮在 where 及 order by 涉及的列上建立索引。

2、不是所有的索引都是有用的，當索引列有大量數據重復時，查詢可能不會去利用索引，也就提高不了查詢效率。

3、索引并不是越多越好，索引在提高查詢效率的同時也降低了插入(insert)和更新(update)的效率，所以在建索引時要慎重考慮，不要放在經常更新的字段上，一張表的索引最好不要超過6個。

三、SQL語句查詢

1、在程序中最好是不要使用select * from t；select count() from t，用具體的字段名代替“”，這樣可以減少數據負擔。如果是多表關聯查詢，不同的表存在相同名稱的字段，也會造成混淆。但如果是在后臺數據庫做臨時查詢，特別是對表字段不熟悉的時候，用select * 就比較方便了。

2、用exists和not exists代替in和not in，因為in 是把外表和內表作hash 連接，而exists是對外表作loop循環，每次loop循環再對內表進行查詢，而且IN不對NULL進行處理，exists會對NULL值進行處理。

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

4、不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

5、后臺盡量不要向前臺返回大數據量，如果數據量過大，更應該注意sql優化，不要返回一些不需要的列，或者也該考慮考慮需求是否合理了。而且盡量避免大事務操作，提高系統的并發能力。

尾聲

大家都是搞后端業務的，雖然業務不盡相同。但對數據庫的使用來說，都是CURD（雖然有些絕對，哈哈）。更好的理解數據庫，不光對個人技術有幫助，長遠來說對業務對發展都有提升~