SQL性能問題已經(jīng)逐步發(fā)展成為數(shù)據(jù)庫性能的首要問題，80%的數(shù)據(jù)庫性能問題都是因SQL而導(dǎo)致。面對日益增多的SQL性能問題，如何下手以及如何提前審核已經(jīng)成為越來越多的程序員必須要考慮的問題。小千總結(jié)了一些容易忽視的幾個SQL優(yōu)化方案，大家一起交流學(xué)習(xí)!

一、避免進(jìn)行null判斷

應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，這里不要給數(shù)據(jù)庫留NULL，盡可能的使用 NOT NULL填充數(shù)據(jù)庫。

備注、描述、評論之類的可以設(shè)置為 NULL，不要使用NULL。不要錯誤的認(rèn)為NULL 不需要空間，如char(100) 型，在字段建立時，空間就固定了。不管是否插入值(NULL也包含在內(nèi))，都是占用 100個字符的空間的，如果是varchar這樣的變長字段， null 不占用空間。可以在num上設(shè)置默認(rèn)值0，確保表中num列沒有null值。

二、不要使用select *

使用select *的話會增加解析的時間，另外也會把不需要的數(shù)據(jù)同時查詢出來，從而延長數(shù)據(jù)傳輸時間，耗費精力。如text類型的字段，通常用來保存一些內(nèi)容比較繁雜的東西，如果使用select *，則會把該字段也查詢出來。

三、謹(jǐn)慎使用模糊查詢

當(dāng)模糊匹配以%開頭時，該列索引將失效。若不以%開頭，該列索引有效。

四、不要使用列號

使用列號的話，將會增加不必要的解析時間。

五、優(yōu)先使用UNION ALL，避免使用UNION

因為UNION 會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務(wù)必使用UNION ALL。還有一種情況，如果業(yè)務(wù)上能夠確保不會出現(xiàn)重復(fù)記錄。

六、在where語句或者order by語句中避免對索引字段進(jìn)行計算操作

當(dāng)在索引列上進(jìn)行操作之后，索引將會失效。正確做法應(yīng)該是將值計算好再傳入進(jìn)來。

七、使用not exist代替not in

如果查詢語句使用了not in 那么內(nèi)外表都進(jìn)行全表掃描，沒有用到索引;而not extsts 的子查詢依然能用到表上的索引。

八、exist和in的區(qū)別

in 是把外表和內(nèi)表作hash 連接，而exists是對外表作loop循環(huán)，每次loop循環(huán)

再對內(nèi)表進(jìn)行查詢。因此，in用到的是外表的索引， exists用到的是內(nèi)表的索引。如果查詢的兩個表大小相當(dāng)，那么用in和exists差別不大。如果兩個表中一個較小，一個是大表，則子查詢表大的用exists，子查詢表小的用in。

九、避免在索引列上做如下操作

1.避免在索引列上使用IS NULL和IS NOT NULL。

2.避免在索引列上出現(xiàn)數(shù)據(jù)類型轉(zhuǎn)換。(比如某字段是String類型，參數(shù)傳入時是int類型)當(dāng)在索引列上使用如上操作時，索引將會失效，造成全表掃描。

十、復(fù)雜操作可以考慮適當(dāng)拆成幾步

有時候會有通過一個SQL語句來實現(xiàn)復(fù)雜業(yè)務(wù)的例子出現(xiàn)，為了實現(xiàn)復(fù)雜的業(yè)務(wù)，嵌套多級子查詢。造成SQL性能問題。對于這種情況可以考慮拆分SQL，通過多個SQL語句實現(xiàn)，或者把部分程序能完成的工作交給程序完成。

總結(jié)

以上是生活随笔為你收集整理的容易忽视的十大SQL优化方案！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。