以前剛開始做項目的時候，開發(fā)經(jīng)驗尚淺，每次遇到查詢比較慢時，項目經(jīng)理就會問：是不是又用select * 了？查詢條件有沒有加索引？一語驚醒夢中人，趕緊檢查..果然如此！

有時我們寫sql語句時，沒有考慮它的性能或者完全沒有優(yōu)化意識，雖然能暫時滿足基本功能，等到數(shù)據(jù)量大時，后果可想而知。

1）盡量不要用select * from table，除非需要返回數(shù)據(jù)庫表的全部字段，否則不要返回用不到的任何字段。因為select * 會導(dǎo)致全表掃描，效率比較低。

2）where子句及order by涉及的列盡量建索引，不一定要全部建索引，依業(yè)務(wù)情形而定。對于多條where子句都用到的列，建議建索引。索引并不是越多越好，索引固然可以提高相應(yīng)的select的效率，但同時也降低了insert及update 的效率。

3） 盡量避免在 where 子句中使用 != 或 <> 操作符，否則引擎將會放棄使用索引而進行全表掃描。 對于不等于這種情況，可考慮改為范圍查詢解決。

4）盡量避免在 where 子句中使用 or 來連接條件，如果一個字段有索引，一個字段沒有索引，引擎將放棄使用索引而進行全表掃描，如：

select id from person_info where age=10 or name= '張三'；

可以這樣查詢：

select id from person_info where age = 10
union all
select id from person_info where name= '張三'

5）盡量避免在 where 子句中對字段進行 null 值判斷，因為空判斷將導(dǎo)致全表掃描，而不是索引掃描。 對于空判斷這種情況，可以考慮對這個列創(chuàng)建數(shù)據(jù)庫默認值。如：

6）in 和 not in 也要慎用，否則會導(dǎo)致全表掃描，如：

select id from person_info where age in(1,2,3)

對于連續(xù)的數(shù)值，能用 between 就不要用 in 了：

select id from person_info where age between 1 and 3

很多時候用 exists 代替 in 是一個好的選擇：

select age from a where age in(select age from b)

用下面的語句替換：

select age from a where exists(select age from b where b.age=a.age)；

7）盡量避免左右模糊查詢，這樣會導(dǎo)致索引失效，進而全表查詢，如：select id from person_info  where name like ‘%abc%’，可以使用右側(cè)模糊查詢，這樣是可以索引查找的，如：select id from person_info  where name like ‘a(chǎn)bc%’；

8）如果在 where 子句中使用參數(shù)或?qū)ψ侄芜M行表達式操作，也會導(dǎo)致全表掃描，如：

select id from person_info  where age/2 = 10

應(yīng)改為: select id from person_info   where age= 10*2；

9）應(yīng)盡量避免在where子句中對字段進行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進行全表掃描。函數(shù)、算術(shù)運算或其他表達式運算通常將導(dǎo)致全表掃描， 對于這種情況，可以考慮冗余部分數(shù)據(jù)到表中。

10）在使用索引字段作為條件時，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統(tǒng)使用該索引，否則該索引將不會被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

11）update 語句，如果只更改1、2個字段，不要update全部字段，否則頻繁調(diào)用會引起明顯的性能消耗，同時帶來大量日志。

12）對于多張大數(shù)據(jù)量（這里幾百條就算大了）的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。

13）select count(*) from table；這樣不帶任何條件的count會引起全表掃描，并且沒有任何業(yè)務(wù)意義，是一定要杜絕的?？梢愿臑閟elect count(id) from table。

14）盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。

15）盡可能的使用varchar代替char，因為首先變長字段存儲空間小，可以節(jié)省存儲空間，其次對于查詢來說，在一個相對較小的字段內(nèi)搜索效率顯然要高些。

陪伴是最長情的告白

每日為你推送Java技術(shù)干貨