這裡簡單介紹mysql資料庫中，幾條被我們忽略的常見問題和優化方式：
1.最左字首匹配原則，非常重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。
盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃瞄的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別字段可能在大資料面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃瞄10條記錄。
2.盡量使用數字型字段，若只含數值資訊的字段盡量不要設計為字元型，這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線時會 逐個比較字串中每乙個字元，而對於數字型而言只需要比較一次就夠了。
3.索引列不能參與計算，保持列「乾淨」，比如from_unixtime(create_time) = 』2014-05-29』就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的字段值，但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp(』2014-05-29』);應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用。
索引而進行全表掃瞄，如：
select id from t where num is null
可以在num上設定預設值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
應盡量避免在 where 子句中使用 or 來連線條件，否則將導致引擎放棄使用索引而進行全表掃瞄，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10 union all select id from t where num=20
下面的查詢也將導致全表掃瞄（不能前置百分號）：
select id from t where name like 『%abc%』
若要提高效率，可以考慮全文檢索。
in 和 not in 也要慎用，否則會導致全表掃瞄，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
mysql 大表優化 持續更新
單錶優化 除非單錶資料未來會一直不斷 否則不要一開始就考慮拆分，拆分會帶來邏輯 部署 運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候mysql單錶的效能依然有不少優化空間，甚至能正常支撐千萬級以上的資料量 字段 索引 查詢sql 總結 ...
mysql優化積累 持續更新中
大表資料查詢 主從複製 讀寫分離 垂直拆分 水平切分 資料庫設計和查詢原則 盡量設定主鍵 推薦使用自增id，不要使用uuid 字段定義為not null而不是null 密碼雜湊，鹽，使用者身份證號等固定長度的字串應該使用char而不是varchar來儲存，這樣可以節省空間且提高檢索效率。避免犯如下s...
mysql優化理解筆記（持續更新）
目前最常見的是innodb和myisam兩個儲存引擎 1 innodb 支援事務處理，提供行級鎖 外來鍵約束索引，行鎖 2 myisam 支援全文搜尋，表鎖 對於經常需要增刪改操作的表建議使用innodb，因為有事務處理 要麼成功要麼失敗回滾 而需要大量查詢操作的表建議用myisam 索引可以大大提...