又是一年一度跳槽季,為了尋求更好的發(fā)展樓主也隨波逐流。再一次面試中被問到Sql優(yōu)化坐求，樓主只是簡單的回答了幾條蚕泽，作為一個有經(jīng)驗的開發(fā)人員居然不知道Sql優(yōu)化，我自己都笑了（不是不知道桥嗤，只是一下想不起那么多）须妻。
為了鞭策自己，決心整理一下常見的SQL優(yōu)化場景泛领，供各位大神批評指點荒吏！也希望大家能幫忙補充。以下表都叫小明(t1)渊鞋，int字段都叫小紅(age)
1. 對查詢進行優(yōu)化绰更，應盡量避免全表掃描 select * from t1 就別用了,用多少差多少吧，別把數(shù)據(jù)庫累死锡宋；
2. 用到條件查詢時儡湾，考慮一下在 where 及 order by 涉及的列上建立索引會不會更好呢。
3. 當然在where 子句中對字段進行 null 值判斷也不是很明智执俩，例如： select id form t1 where age is null 可以在num上設置默認值0徐钠，確保表中num列沒有null值，然后這樣查詢： select id form t1 where age =0 豈不是更好;
- where 子句中使用!=或< , >操作符役首，會導致引擎放棄使用索引而進行全表掃描,使用是多加考慮一下
- 應盡量避免在 where 子句中使用 or 來連接條件丹皱，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where age=10 or age=20
可以這樣查詢：
select id from t where age=10 union all select id from t where age=20 - in 和 not in 也要慎用宋税，否則會導致全表掃描，如：
select id from t where age in(1,2,3)
對于連續(xù)的數(shù)值讼油，能用 between 就不要用 in 了：
select id from t where agebetween 1 and 3 - like 百分百(
like %name%)也少用吧 , 數(shù)據(jù)庫承受不了你模糊的愛; - 應盡量避免在 where 子句中對字段進行表達式操作杰赛，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where age/2=100
應改為:
select id from t where age=100*2 - 應盡量避免在where子句中對字段進行函數(shù)操作矮台，這將導致引擎放棄使用索引而進行全表掃描乏屯。如：
select id from t where substring(name,1,3)='abc'
--name以abc開頭的id應改為:
select id from t where name like 'abc%' - 不要在 where 子句中的“=”左邊進行函數(shù)、算術運算或其他表達式運算瘦赫，否則系統(tǒng)將可能無法正確使用索引辰晕。
- where 條件能過濾數(shù)據(jù)最多的放在最左邊,先將無用的數(shù)據(jù)排除。
- 在使用索引字段作為條件時确虱，如果該索引是復合索引含友，那么必須使用到該索引中的第一個字段作為條件時才能保證系統(tǒng)使用該索引，
否則該索引將不會被使用，并且應盡可能的讓字段順序與索引順序相一致窘问。 - 不要寫一些沒有意義的查詢辆童，如需要生成一個空表結(jié)構：
select col1,col2 into #t1 from t1 where 1=0
這類代碼不會返回任何結(jié)果集，但是會消耗系統(tǒng)資源的惠赫，應改成這樣：
create table #t1(...) - 不讓用in not in 咋辦 ? 用 exists( not exists) 代替 in(not in) 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num) - 并不是所有索引對查詢都有效把鉴，SQL是根據(jù)表中數(shù)據(jù)來進行查詢優(yōu)化的，當索引列有大量數(shù)據(jù)重復時儿咱，SQL查詢可能不會去利用索引庭砍，
如一表中有字段sex，male混埠、female幾乎各一半怠缸，那么即使在sex上建了索引也對查詢效率起不了作用。 - 索引并不是越多越好岔冀，索引固然可以提高相應的 select 的效率凯旭，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引使套，所以怎樣建索引需要慎重考慮罐呼，視具體情況而定。一個表的索引數(shù)最好不要超過6個侦高，若太多則應考慮一些不常使用到的列上建的索引是否有必要嫉柴。
- 盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設計為字符型奉呛，這會降低查詢和連接的性能计螺，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符瞧壮，而對于數(shù)字型而言只需要比較一次就夠了登馒。
- 盡可能的使用 varchar 代替 char ，因為首先變長字段存儲空間小咆槽，可以節(jié)省存儲空間陈轿，其次對于查詢來說，在一個相對較小的字段內(nèi)搜索效率顯然要高些秦忿。
- 避免頻繁創(chuàng)建和刪除臨時表麦射，以減少系統(tǒng)表資源的消耗。
- 臨時表并不是不可使用灯谣，適當?shù)厥褂盟鼈兛梢允鼓承├谈行鼻铮纾斝枰貜鸵么笮捅砘虺Ｓ帽碇械哪硞€數(shù)據(jù)集時胎许。但是峻呛，對于一次性事件罗售，最好使用導出表。
- 在新建臨時表時杀饵，如果一次性插入數(shù)據(jù)量很大莽囤，那么可以使用 select into 代替 create table，避免造成大量 log 切距，以提高速度朽缎；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源谜悟，應先create table话肖，然后insert。
- 如果使用到了臨時表葡幸，在存儲過程的最后務必將所有的臨時表顯式刪除最筒，先 truncate table ，然后 drop table 蔚叨，這樣可以避免系統(tǒng)表的較長時間鎖定床蜘。
- 盡量避免使用游標，因為游標的效率較差蔑水，如果游標操作的數(shù)據(jù)超過1萬行邢锯，那么就應該考慮改寫。
- 使用基于游標的方法或臨時表方法之前搀别，應先尋找基于集的解決方案來解決問題丹擎，基于集的方法通常更有效。
25.與臨時表一樣歇父，游標并不是不可使用蒂培。對小型數(shù)據(jù)集使用FAST_FORWARD 游標通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數(shù)據(jù)時榜苫。 - 在結(jié)果集中包括“合計”的例程通常要比使用游標執(zhí)行的速度快护戳。如果開發(fā)時間允許，基于游標的方法和基于集的方法都可以嘗試一下垂睬，看哪一種方法的效果更好灸异。
- 盡量避免大事務操作，提高系統(tǒng)并發(fā)能力羔飞。26.盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大檐春，應該考慮相應需求是否合理逻淌。
就這么多了,再多面試官就該攆人了......大家多多包涵
