資料庫已成為網際網路應用必不可少的底層依賴，其中mysql作為開源資料庫得到了更加廣泛的應用。最近一直專注於專案工程的開發，對開發過程中使用到的一些關於資料庫的優化原則進行了總結，希望能夠幫助更多的應用開發人員更好的使用mysql資料庫。
mysql的優化主要包括三個方面，首先是sql語句的優化，其次是表結構的優化，這裡主要指索引的優化，最後是伺服器配置的優化。
1．sql語句的優化
1)查詢語句應該盡量避免全表掃瞄，首先應該考慮在where子句以及orderby子句上建立索引，但是每一條sql語句最多隻會走一條索引，而建立過多的索引會帶來插入和更新時的開銷，同時對於區分度不大的字段，應該盡量避免建立索引，可以在查詢語句前使用explain關鍵字，檢視sql語句的執行計畫，判斷該查詢語句是否使用了索引；
2)應盡量使用exist和not exist代替 in和not in，因為後者很有可能導致全表掃瞄放棄使用索引；
3)應盡量避免在where子句中對字段進行null判斷，因為null判斷會導致全表掃瞄；
4)應盡量避免在where子句中使用or作為連線條件，因為同樣會導致全表掃瞄；
5)應盡量避免在where子句中使用！=或者<>操作符，同樣會導致全表掃瞄；
6)使用like 「%abc%」 或者like 「%abc」 同樣也會導致全表掃瞄，而like 「abc%」會使用索引。
7)在使用union操作符時，應該考慮是否可以使用union all來代替，因為union操作符在進行結果合併時，會對產生的結果進行排序運算，刪除重覆記錄，對於沒有該需求的應用應使用union all，後者僅僅只是將結果合併返回，能大幅度提高效能；
8)應盡量避免在where子句中使用表示式操作符，因為會導致全表掃瞄；
9)應盡量避免在where子句中對字段使用函式，因為同樣會導致全表掃瞄
10)select語句中盡量 避免使用「*」，因為在sql語句在解析的過程中，會將「*」轉換成所有列的列名，而這個工作是通過查詢資料字典完成的，有一定的開銷；
11)where子句中，表連線條件應該寫在其他條件之前，因為where子句的解析是從後向前的，所以盡量把能夠過濾到多數記錄的限制條件放在where子句的末尾；
12)若資料庫表上存在諸如index(a,b,c)之類的聯合索引，則where子句中條件欄位的出現順序應該與索引欄位的出現順序一致，否則將無法使用該聯合索引；
13)from子句中表的出現順序同樣會對sql語句的執行效能造成影響，from子句在解析時是從後向前的，即寫在末尾的表將被優先處理，應該選擇記錄較少的表作為基表放在後面，同時如果出現3個及3個以上的表連線查詢時，應該將交叉表作為基表；
14)盡量使用》=操作符代替》操作符，例如，如下sql語句，select dbinstanceidentifier from dbinstance where id > 3，該語句應該替換成 select dbinstanceidentifier from dbinstance where id >=4 ，兩個語句的執行結果是一樣的，但是效能卻不同，後者更加 高效，因為前者在執行時，首先會去找等於3的記錄，然後向前掃瞄，而後者直接定位到等於4的記錄。
2．表結構的優化
這裡主要指如何正確的建立索引，因為不合理的索引會導致查詢全表掃瞄，同時過多的索引會帶來插入和更新的效能開銷；
1)首先要明確每一條sql語句最多隻可能使用乙個索引，如果出現多個可以使用的索引，系統會根據執行代價，選擇乙個索引執行；
2)對於innodb表，雖然如果使用者不指定主鍵，系統會自動生成乙個主鍵列，但是自動產生的主鍵列有多個問題1. 效能不足，無法使用cache讀取；2. 併發不足，系統所有無主鍵表，共用乙個全域性的auto_increment列。因此，innodb的所有表，在建表同時必須指定主鍵。
3)對於區分度不大的字段，不要建立索引；
4)乙個欄位只需建一種索引即可，無需建立了唯一索引，又建立index索引。
5)對於大的文字字段或者blob欄位，不要建立索引；
6)連線查詢的連線字段應該建立索引；
7)排序字段一般要建立索引；
8)分組統計字段一般要建立索引；
9)正確使用聯合索引，聯合索引的第乙個欄位是可以被單獨使用的，例如有如下聯合索引index(userid,dbinstanceid),一下查詢語句是可以使用該索引的，select dbinstanceidentifier from dbinstance where userid=? ，但是語句select dbinstanceidentifier from dbinstance where dbinstanceid=?就不可以使用該索引；
10)索引一般用於記錄比較多的表，假如有表dbinstance，所有查詢都有userid條件字段，目前已知該欄位已經能夠很好的區分記錄，即每乙個userid下記錄數量不多，所以該錶只需在userid上建立乙個索引即可，即使有使用其他條件字段，由於每乙個userid對應的記錄資料不多，所以其他字段使用不用索引基本無影響，同時也可以避免建立過多的索引帶來的插入和更新的效能開銷；
3．mysql伺服器配置優化
mysql伺服器配置優化主要是指mysql引數的優化；
1)mysql伺服器有慢連線日誌，可以將超過一定時間間隔和不使用索引的查詢語句記錄下來方便開發人員跟蹤，可以通過設定slow_query_log=on/off開啟和關閉慢連線日誌功能，slow_query_log_file設定慢連線日誌的檔名，long_query_time設定超時時間，單位是ms,注意慢連線日誌mysql預設是關閉的；
2)mysql有查詢快取的功能，伺服器會儲存查詢語句和相應的返回結果來減少相同的查詢造成的伺服器開銷，可以通過設定query_cache_size設定查詢快取的大小，0表示關閉查詢快取，但是值得注意的是，一旦該錶有更新，則所有的查詢快取都會失效，預設情況下，mysql是關閉查詢快取的；
3)可以通過配置max_connections設定資料庫的最大連線數，wait_timeout設定連線最長保留時間，該時間單位是s, mysql預設是8個小時，一旦超過8個小時，資料庫會自動斷開該連線，這點在使用資料庫連線池時由為需要注意，因為連線池中的連線可能已經被伺服器斷開了，到那時連線池不知道，應用在從連線池中獲取到該連線使用時就會出錯，max_connect_errors配置如果應用出現多次異常，則會終止主機連線資料庫；
2. mysql最新手冊教程
3.資料庫設計那些事
三方面搞定http協議之「報文模型」
關於http協議，這一塊的知識其實相當大，但是作為乙個前端開發者來說，我覺得只要知道三方面的內容就足矣把http協議是個什麼東西解釋清楚了。而這三方面，就是http的報文模型，請求方式以及狀態碼。這篇我們就來看報文模型。首先，報文是指網路傳輸與交換資料的基本單位，可以把它理解為乙個裝好了完整資料資訊...
三方面搞定http協議之「請求方法」
我所熟知的請求方法一共有六種 get 請求指定的頁面資訊，並返回實體主體。post 向指定資源提交資料進行處理請求 例如提交表單或者上傳檔案 put 從客戶端向伺服器傳送的資料取代指定的文件的內容。delete 請求伺服器刪除指定的頁面 head 返回的響應中的報頭 options 檢視伺服器的效能...
三方面搞定http協議之「報文模型」
關於http協議，這一塊的知識其實相當大，但是作為乙個前端開發者來說，我覺得只要知道三方面的內容就足矣把http協議是個什麼東西解釋清楚了。而這三方面，就是http的報文模型，請求方式以及狀態碼。這篇我們就來看報文模型。首先，報文是指網路傳輸與交換資料的基本單位，可以把它理解為乙個裝好了完整資料資訊...