詳細的MySQL最佳化步驟如下：
因為建表的時候，如果沒有對建立的值設定預設值，MySQL都會設定預設為NULL。那麼為啥用NULL不好呢？
NULL使得索引維護更加複雜，強烈建議對索引列設定#NOT NULL
NOT IN 、!=等負向條件查詢在有NULL值的情況下傳回永遠為空結果，查詢容易出錯NULL列需要一個額外位元組作為判斷是否為NULL的標誌位元NULL時和該列其他的值可能不是同種類型，導致問題。 （在不同的語言中表現不一樣）NULL的列的查詢所以對於那些以前偷懶的字段，手動設定一個預設值吧，空字串呀，0呀補上。
雖然這種方法對於MySQL的效能來說沒有提升多少，但這是一個好習慣，而且以小見大，不要忽略這些細節。
對於經常查詢的字段，請加上索引，有索引和沒有索引的查詢速度相差十倍甚至更多。
id欄位#varchar類型的字段，在建立索引的時候，最好指定長度LIKE 條件這樣的模糊搜尋對於字段索引是無效的，需要另外建立關鍵字索引來解決當表和表之間有約束時，雖然增刪查的SQL語句變簡單了，但是帶來的負面效果是插入等操作資料庫都會去檢查約束（雖然可以手動設定忽略約束），這樣相當於把一些業務邏輯寫到了資料庫層，不便於維護。
資料庫中那些可以用整形表示的資料就不要使用字串類型，到底是用varchar還是char要看欄位的可能值。
這種最佳化往往在資料庫中有大量資料以後是不可行的，最好在資料庫設計之前就設計好。
tinyint取代VARCHAR，ENUM呢？ ENUM擴充困難，例如後來移動平台又增加了一個ipad，那豈不是懵逼了，而tinyint加個2就行，而且 ENUM在程式碼裡面處理起來特別奇怪，是當成整形呢還是字串，各個語言不一樣。 char，例如郵編，總是5位元varchar
bigint，例如記錄文章數目的表id字段，用int就行了，21億篇文章上限夠了查詢的時候，肯定int類型比varchar快，因為整數的比較直接呼叫底層運算器就可以實現，而字串比較要逐個字元比較。
定長資料比變長資料查詢快，因為比較定長資料與資料之間的偏移是固定的，很容易計算下一個資料的偏移。而變長資料則還需要多一步去查詢下一個資料的偏移。不過。定長資料可能會浪費更多的儲存空間。
對於那些資料量可能近期會超過500W或成長很快的表，一定要提前做好垂直分錶或水平分錶，當數據量超過百萬以後，查詢速度會明顯下降。
分庫分錶盡量在資料庫設計初期敲定方案，否則後期會大幅增加程式碼複雜度而且不易變更。
垂直分錶是依照日期等外部變數進行分錶，水平分錶是依照表中的某些欄位關係，使用hash映射等分錶。
分庫分錶的前提條件是在執行查詢語句之前，已經知道需要查詢的資料可能會落在哪一個分庫和哪一個分錶中。
這個才是許多系統資料庫瓶頸的始作俑者。
LIKE
is null的列or
使用redis等緩存，還有本機檔案快取等，可以大幅減少資料庫查詢次數。快取這個東西，一定要分析自己系統的資料特點，適當選擇。
推薦學習：《mysql影片教學》
以上是總結MySQL優化最最基礎的操作的詳細內容。更多資訊請關注PHP中文網其他相關文章！
