資料庫優化走一下幾個流程：
1、盡可能不要使用null值。
(1)null使索引維護更加複雜，推薦給索引列使用not null;
(2)查詢容易出錯。not in、！=等查詢再有null值的情況下返回結構總是空。
(3)需要額外位元組作為判斷是否為null的標誌位
(4)可能跟該列的其他值不是同種型別，導致問題。
(5)mysql難以優化對null列的查詢
所以對那些字段手動設定是最佳選擇。
對於經常查詢的字段，**上索引，有索引和沒有索引的查詢速度相差十倍甚至更多。
1.一般來說，每張表都需要有乙個主鍵id字段
2.常用於查詢的字段應該設定索引
3.varchar型別的字段，在建立索引的時候，最好指定長度
4.查詢有多個條件時，優先使用具有索引的條件
6.請盡量不要在資料庫層面約束表和表之間的關係，這些表之間的依賴應該在**層面去解決
當表和表之間有約束時，雖然增刪查的sql語句變簡單了，但是帶來的負面效果是插入等運算元據庫都會去檢查約束（雖然可以手動設定忽略約束），這樣相當於把一些業務邏輯寫到了資料庫層，不便於維護。
資料庫中那些可以用整形表示的資料就不要使用字串型別，到底是用varchar還是char要看字段的可能值。
這種優化往往在資料庫中有大量資料以後是不可行的，最好在資料庫設計之前就設計好。
對於那些定長字串，可以使用char，比如郵編，總是5位
對於那些長度未知的字串，使用varchar
不要濫用bigint，比如記錄文章數目的表id字段，用int就行了，21億篇文章上限夠了
適當打破資料庫正規化新增冗餘字段，避免查詢時的表連線
查詢的時候，肯定int型別比varchar快，因為整數的比較直接呼叫底層運算器就可以實現，而字串比較要逐個字元比較。
這個才是很多系統資料庫瓶頸的始作俑者。
多條件查詢時，請把簡單查詢條件或者索引列查詢置於前面
請盡量指定需要查詢的列，不要偷懶使用select *
大寫的查詢關鍵字比小寫快一點點
使用子查詢會建立臨時表，會比鏈結（join）和聯合（union）稍慢
在索引欄位上查詢盡量不要使用資料庫函式，不便於快取查詢結果
當只要一行資料時，請使用limit 1，如果資料過多，請適當設定limit，分頁查詢
千萬不要 order by rand()，效能極低
上面是我總結的一些小tips，這些規則是死的，但是業務場景是活的，在實際使用的過程中，比如資料統計，可以適當犧牲效能換取便利。
對於那些資料量可能近期會超過500w或者增長很快的表，一定要提前做好垂直分表或者水平分表，當資料量超過百萬以後，查詢速度會明顯下降。
分庫分表盡量在資料庫設計初期敲定方案，否則後期會極大增加**複雜性而且不易更改。
垂直分表是按照日期等外部變數進行分表，水平分表是按照表中的某些字段關係，使用hash對映等分表。
分庫分表的前提條件是在執行查詢語句之前，已經知道需要查詢的資料可能會落在哪乙個分庫和哪乙個分表中。
使用redis等快取，還有本地檔案快取等，可以極大地減少資料庫查詢次數。快取這個東西，一定要分析自己系統的資料特點，適當選擇。
這個才是很多系統資料庫瓶頸的始作俑者。
多條件查詢時，請把簡單查詢條件或者索引列查詢置於前面
請盡量指定需要查詢的列，不要偷懶使用select *
大寫的查詢關鍵字比小寫快一點點
使用子查詢會建立臨時表，會比鏈結（join）和聯合（union）稍慢
在索引欄位上查詢盡量不要使用資料庫函式，不便於快取查詢結果
當只要一行資料時，請使用limit 1，如果資料過多，請適當設定limit，分頁查詢
千萬不要 order by rand()，效能極低
上面是我總結的一些小tips，這些規則是死的，但是業務場景是活的，在實際使用的過程中，比如資料統計，可以適當犧牲效能換取便利。
下面舉幾個簡單的優化查詢例子。首先就是跑一下主要業務，把主要的查詢語句列印到乙個檔案裡面，然後分析這些語句。
補充一下，在查詢語句前使用關鍵字explain可以檢視查詢執行的具體情況。
看下面的這個查詢語句
上面這條語句毛病挺多的
顯然查詢條件很多，而且很多列都是不定長的varchar型別，如果要建立索引，是不是要建立聯合索引呢？
這樣的查詢語句要結合具體的業務場景來進行分析，比如在我當前的系統中，我是期望上面的語句能夠查詢相同的引數下是否有記錄。其實沒必要使用這麼多條件的查詢。
我只需要使用下面的這條更簡單的查詢語句代替即可。
查詢到的記錄條數在100條以下，大部分就只用幾十條記錄，我完全可以在**裡面在把查詢結果遍歷一遍判斷即可。這樣不知道有多快呢！
再看下面的這個例子：
我只是想查一下這個表裡面某個時間以後的資料。問題大了！
created欄位是timestamp型別，這樣用是不對的，而且沒有限定行數，這條語句會把資料庫所有的device_id='52'的資料搞出來。
還好device_id字段設定了索引，要不然必然會導致全表掃瞄。
修改後的查詢如下：
我的專案中並沒有使用複雜的像表連線和聯合這樣的查詢，這類查詢一定要謹慎使用，能夠拆分的話盡量拆分。
記住下面的速度優先順序，兩兩之間相差2個以上數量級
cpu執行速度 > 記憶體訪問速度 > 磁碟io訪問速度 > 網路請求速度
mysql資料庫優化索引 mysql資料庫索引調優
一 mysql索引 1 磁碟檔案結構 innodb引擎 frm格式檔案儲存表結構，ibd格式檔案儲存索引和資料。myisam引擎 frm格式檔案儲存表結構，myi格式檔案儲存索引，myd格式檔案儲存資料 2 mysql資料庫資料範問原理 innodb btree 1 ibd檔案中主鍵構建b tree...
mysql資料庫優先 MySQL資料庫優化
1.新增索引 mysql資料庫的四類索引 index 普通索引,資料可以重複，沒有任何限制。unique 唯一索引,要求索引列的值必須唯一，但允許有空值 如果是組合索引，那麼列值的組合必須唯一。primary key 主鍵索引,是一種特殊的唯一索引，乙個表只能有乙個主鍵，不允許有空值，一般是在建立表...
mysql資料庫優化
用到啥學啥，mysql資料庫優化成了這幾天的老大難問題。瘋狂的尋找mysql優化的資料，覺得有用的不少，記錄下跟大家分享，對了，這裡僅僅是mysql資料庫本身的優化，沒有寫磁碟之類的 開始之前，介紹倆mysql的命令 show global status 檢視執行狀態的，顯示執行各種狀態值 show...