作者：曹理鵬@iCocos
來源：https://icocos.github.io/2019/03/11/數據庫查詢速度優化之解決技巧/
1、對查詢進行優化,應盡可能避免全表掃描
首先應考慮在 where 及 order by 涉及的列上建立索引。
下面我們來以一個表中177條數據比較一下,全表掃描與建立索引之后性能的一個比較.
從這兩種方式查詢數據庫結果看,建立索引之后查詢速度提高了些,現在數據量還不明顯,如果表中有10萬條速度,差異就會很明顯了.
2、寫數據語句時盡可能減少表的全局掃描
1）減少where 字段值null判斷
SELECT * FROM "tb_real_time_car" where pay_status = null
如何這樣做,就會導致引擎放棄使用索引而進行全表掃描
應該這樣去設置(也就是在沒有值時,我們在存數據庫時自動默認給個o值,而不是什么都不寫):
SELECT * FROM "tb_real_time_car" where pay_status = 0
2）應盡量避免在 where 子句中使用!=或<>操作符
SELECT * FROM "tb_real_time_car" where pay_status != null ; //或者 SELECT * FROM "tb_real_time_car" where pay_status <> null ;
這樣寫將導致引擎放棄使用索引而進行全表掃描。
3）應盡量避免在 where 子句中使用 or 來連接條件
SELECT * FROM "tb_real_time_car" where pay_status != null or enter_time = null;
這樣將導致引擎放棄使用索引而進行全表掃描
可以這樣操作:
SELECT * FROM "tb_real_time_car" where pay_status != null union all SELECT * FROM "tb_real_time_car" where enter_time = null;
4）in 和 not in 也要慎用
SELECT * FROM "tb_real_time_car" where rowed in [1,2,3,4]; //或者 SELECT * FROM "tb_real_time_car" where rowed not in [1,2,3,4];
這樣操作,也會導致全表掃描
可以這樣來寫:
SELECT * FROM "tb_real_time_car" where rowed between 1 and 5;
5）少使用模糊匹配 like
SELECT * FROM "tb_real_time_car" where enter_time like '%2016-09-01%'
6）應盡量避免在 where 子句中對字段進行表達式操作
SELECT * FROM "tb_real_time_car" where rowid/4 =100;
這樣寫,將導致引擎放棄使用索引而進行全表掃描
應該寫成:
SELECT * FROM "tb_real_time_car" where rowid =4*100;
7）任何地方都不要使用*通配符去查詢所有
SELECT * FROM "tb_real_time_car" where rowid/4 =100;
以通配符*去查詢所有數據,這樣做也是非常耗時的,我們應該需要什么字段就查詢什么字段.
應該這樣做:
SELECT leave_time FROM "tb_real_time_car" where rowid/4 =100;
3、不要在條件判斷時進行 算數運算
SELECT * FROM "tb_real_time_car" where rowid/4 =100;
所以不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算,這樣系統將可能無法正確使用索引
應該這樣做:
SELECT * FROM "tb_real_time_car" where rowed =400;
4、很多時候用 exists 代替 in 是一個好的選擇
SELECT * FROM "tb_real_time_car" where rowed (select rowed from "tb_real");
應該這樣來寫:
SELECT * FROM "tb_real_time_car" where exists (select rowed from "tb_real" where rowed = tb_real.rowid);
5、論索引技巧
1）并不是所有索引對查詢都有效
SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用
2）索引并不是越多越好
索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
3）應盡可能的避免更新 clustered 索引數據列
因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那么需要考慮是否應將該索引建為 clustered 索引。
4）盡量使用數字型字段
若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數字型而言只需要比較一次就夠了。
6、創建數據庫時應該注意地方
1）盡可能的使用 varchar/nvarchar 代替 char/nchar
因為首先變長字段存儲空間小，可以節省存儲空間，其次對于查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
2）用表變量來代替臨時表。
a. 如果表變量包含大量數據，請注意索引非常有限（只有主鍵索引）。
b. 在新建臨時表時，如果一次性插入數據量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然后insert。
c. 如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統表的較長時間鎖定。
3）避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
4）盡量避免使用游標
a. 因為游標的效率較差，如果游標操作的數據超過1萬行，那么就應該考慮改寫。
b. 使用基于游標的方法或臨時表方法之前，應先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。
c. 與臨時表一樣，游標并不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括“合計”的例程通常要比使用游標執行的速度快。如果開發時間允許，基于游標的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。
7、數據放回時注意什么
1）盡量避免大事務操作，提高系統并發能力。
這樣可以有效提高系統的并發能力
2）盡量避免向客戶端返回大數據量
若數據量過大，應該考慮相應需求是否合理。
