- 盡量避免全表掃描，首先考慮在where和order by涉及的列上簡歷索引
- 避免在where子句中對字段進行null判斷，所以最好在創(chuàng)建表的時候給每個字段都加默認值
- 避免在where中使用 != 或 <> ，MYSQL只有對以下操作符才使用索引： < , <= , = , > , >= , BETWEEN , IN 以及某些時候的LIKE
- 避免在where中使用or权烧，用了or會導致引擎放棄使用索引而使用全表掃描， 可以使用UNION 替代or
- in和not in也要慎用需纳，否則會導致全表掃描骗随，對于連續(xù)的數(shù)值蛤织，能用between就不要用in了：Select id from t where num between 1 and 3
- LIKE只有在 “abc%”的情況下才會用到索引，“%abc%”會導致全表掃描
- where中避免使用表達式操作
- 很多時候用exists代替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)
- 索引固然可以提高相應(yīng)的select的效率指蚜，但同時也降低了insert及update的效率，因為insert或update時有可能會重建索引涨椒，所以怎樣建索引需要慎重考慮摊鸡，視具體情況而定。一個表的索引數(shù)最好不要超過6個蚕冬，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要
- 盡量使用數(shù)字型字段免猾，若只含數(shù)值信息的字段盡量不要設(shè)計為字符型，這會降低查詢和連接的性能囤热，并會增加存儲開銷
- 最好不要使用 ”*“ 返回所有：select from t 猎提，用具體的字段列表代替 “*” ，不要返回用不到的任何字段
- 使用表的別名(Alias)：當在SQL語句中連接多個表時旁蔼，請使用表的別名并把別名前綴于每個Column上锨苏。這樣一來，就可以減少解析的時間并減少那些由Column歧義引起的語法錯誤
- 在IN后面值的列表中棺聊，將出現(xiàn)最頻繁的值放在最前面伞租，出現(xiàn)得最少的放在最后面，減少判斷的次數(shù)
- 盡量使用exists代替select count(1)來判斷是否存在記錄限佩，count函數(shù)只有在統(tǒng)計表中所有行數(shù)時使用葵诈，而且count(1)比count(*)更有效率
- 盡量使用“>=”，不要使用“>”
- 下列SQL條件語句中的列都建有恰當?shù)乃饕钔珗?zhí)行速度卻非常慢：
SELECT * FROM record WHERE substrINg(card_no,1,4)=’5378’ (13秒)
SELECT * FROM record WHERE amount/30< 1000 （11秒）
SELECT * FROM record WHERE convert(char(10),date,112)=’19991201’ （10秒）
分析：
WHERE子句中對列的任何操作結(jié)果都是在SQL運行時逐列計算得到的驯击，因此它不得不進行表搜索，而沒有使用該列上面的索引耐亏。
如果這些結(jié)果在查詢編譯時就能得到徊都，那么就可以被SQL優(yōu)化器優(yōu)化，使用索引广辰，避免表搜索暇矫，因此將SQL重寫成下面這樣：
SELECT * FROM record WHERE card_no like ‘5378%’ （< 1秒）
SELECT * FROM record WHERE amount< 1000*30 （< 1秒）
SELECT * FROM record WHERE date= ‘1999/12/01’ （< 1秒）
- 提高GROUP BY語句的效率，可以通過將不需要的記錄在GROUP BY之前過濾掉择吊。下面兩個查詢返回相同結(jié)果李根，但第二個明顯就快了許多
-- 低效
SELECT JOB , AVG(SAL) FROM EMP GROUP BY JOB HAVING JOB =’PRESIDENT’ OR JOB =’MANAGER’
-- 高效
SELECT JOB , AVG(SAL) FROM EMP WHERE JOB =’PRESIDENT’ OR JOB =’MANAGER’ GROUP BY JOB
SQL語句用大寫，因為Oracle總是先解析SQL語句几睛，把小寫的字母轉(zhuǎn)換成大寫的再執(zhí)行
別名的使用房轿，別名是大型數(shù)據(jù)庫的應(yīng)用技巧，就是表名、列名在查詢中以一個字母為別名囱持，查詢速度要比建連接表快1.5倍
-
索引創(chuàng)建規(guī)則：
- 表的主鍵夯接、外鍵必須有索引；
- 數(shù)據(jù)量超過300的表應(yīng)該有索引纷妆；
- 經(jīng)常與其他表進行連接的表盔几，在連接字段上應(yīng)該建立索引；
- 經(jīng)常出現(xiàn)在Where子句中的字段掩幢，特別是大表的字段逊拍，應(yīng)該建立索引；
- 索引應(yīng)該建在選擇性高的字段上际邻；
- 索引應(yīng)該建在小字段上芯丧，對于大的文本字段甚至超長字段，不要建索引世曾；
- 復合索引的建立需要進行仔細分析缨恒，盡量考慮用單字段索引代替；
- 正確選擇復合索引中的主列字段度硝，一般是選擇性較好的字段肿轨；
- 復合索引的幾個字段是否經(jīng)常同時以AND方式出現(xiàn)在Where子句中寿冕？單字段查詢是否極少甚至沒有蕊程？如果是，則可以建立復合索引驼唱；否則考慮單字段索引藻茂；
- 如果復合索引中包含的字段經(jīng)常單獨出現(xiàn)在Where子句中，則分解為多個單字段索引玫恳；
- 如果復合索引所包含的字段超過3個辨赐，那么仔細考慮其必要性，考慮減少復合的字段京办；
- 如果既有單字段索引掀序，又有這幾個字段上的復合索引，一般可以刪除復合索引惭婿；
- 頻繁進行數(shù)據(jù)操作的表不恭，不要建立太多的索引；
- 刪除無用的索引财饥，避免對執(zhí)行計劃造成負面影響换吧；
- 表上建立的每個索引都會增加存儲開銷，索引對于插入钥星、刪除沾瓦、更新操作也會增加處理上的開銷。另外，過多的復合索引贯莺，在有單字段索引的情況下风喇，一般都是沒有存在價值的；相反乖篷，還會降低數(shù)據(jù)增加刪除時的性能响驴，特別是對頻繁更新的表來說，負面影響更大
- 盡量不要對數(shù)據(jù)庫中某個含有大量重復的值的字段建立索引
我們應(yīng)該為數(shù)據(jù)庫里的每張表都設(shè)置一個ID做為其主鍵撕蔼，而且最好的是一個INT型的（推薦使用UNSIGNED）豁鲤，并設(shè)置上自動增加的AUTO_INCREMENT標志
當只要一行數(shù)據(jù)時使用LIMIT 1
-
優(yōu)化表的數(shù)據(jù)類型，選擇合適的數(shù)據(jù)類型：
原則：更小通常更好鲸沮，簡單就好琳骡，所有字段都得有默認值，盡量避免null
例如：數(shù)據(jù)庫表設(shè)計時候更小的占磁盤空間盡可能使用更小的整數(shù)類型讼溺。(mediumint就比int更合適)
比如時間字段：datetime和timestamp楣号，datetime占用8個字節(jié)，而timestamp占用4個字節(jié)怒坯，只用了一半炫狱，而timestamp表示的范圍是1970—2037適合做更新時間
MySQL可以很好的支持大數(shù)據(jù)量的存取，但是一般說來剔猿，數(shù)據(jù)庫中的表越小视译，在它上面執(zhí)行的查詢也就會越快
因此，在創(chuàng)建表的時候归敬，為了獲得更好的性能酷含，我們可以將表中字段的寬度設(shè)得盡可能小
例如：在定義郵政編碼這個字段時，如果將其設(shè)置為CHAR(255)汪茧，顯然給數(shù)據(jù)庫增加了不必要的空間椅亚。甚至使用VARCHAR這種類型也是多余的，因為CHAR(6)就可以很好的完成任務(wù)了
同樣的舱污，如果可以的話呀舔，我們應(yīng)該使用MEDIUMINT而不是BIGIN來定義整型字段，應(yīng)該盡量把字段設(shè)置為NOT NULL扩灯，這樣在將來執(zhí)行查詢的時候媚赖，數(shù)據(jù)庫不用去比較NULL值
對于某些文本字段，例如“省份”或者“性別”驴剔，我們可以將它們定義為ENUM類型省古。因為在MySQL中，ENUM類型被當作數(shù)值型數(shù)據(jù)來處理丧失，而數(shù)值型數(shù)據(jù)被處理起來的速度要比文本類型快得多這樣豺妓，我們又可以提高數(shù)據(jù)庫的性能
- 字符串數(shù)據(jù)類型：char，varchar，text選擇區(qū)別
- 任何對列的操作都將導致表掃描琳拭，它包括數(shù)據(jù)庫函數(shù)训堆、計算表達式等等，查詢時要盡可能將操作移至等號右邊
