MYSQL數據庫的設計與調優

優化思路：

1.檢查數據表結構，改善不完善設計

2.跑一遍主要業務，收集經常使用的數據庫查詢SQL

3.分析查詢SQL，適當拆分，添加索引等優化查詢

4.優化SQL的同時，優化代碼邏輯

5.添加本地緩存和redis緩存

6.增長數據庫硬件配置和增長讀寫分離

檢查數據表結構

看數據表結構設計是否合理。

儘量不要使用NULL值

建表的時候若是不對建立的值設置默認值，MYSQL設置默認都會爲NULL。

　　NULL使得索引維護更加複雜，強烈建議對索引列設置NOT NULL

　　NOT IN、!=等負向條件查詢在有NULL值的狀況下返回永遠爲空結果，查詢容易出錯。

　　NULL列須要一個額外字節做爲判斷是否爲NULL的標誌位。

　　使用NULL時和該列其餘的值可能不是同種類型，致使問題。（在不一樣的語言中表現不同）。

　　MySQL難以優化爲NULL的列的查詢。

添加索引

 

對於常常查詢的字段，請加上索引，有索引和沒有索引的查詢速度相差十倍甚至更多。

 

通常來講，每張表都須要有一個主鍵id字段經常使用於查詢的字段應該設置索引varchar類

型的字段，在創建索引的時候，最好指定長度查詢有多個條件時，優先使用具備索引

的條件像LIKE條件這樣的模糊搜索對於字段索引是無效的，須要另外創建關鍵詞索引

來解決請儘可能不要在數據庫層面約束表和表之間的關係，這些表之間的依賴應該在代

碼層面去解決。當表和表之間有約束時，雖然增刪查的SQL語句變簡單了，可是帶來

的負面效果是插入等操做數據庫都會去檢查約束（雖然能夠手動設置忽略約束），這

樣至關於把一些業務邏輯寫到了數據庫層，不便於維護。

 

優化表字段結構

 

數據庫中那些能夠用整形表示的數據就不要使用字符串類型，究竟是用varchar仍是char

 

要看字段的可能值。這種優化每每在數據庫中有大量數據之後是不可行的，最好在數據庫

設計以前就設計好。對於那些可能值頗有限的列，使用tinyint代替VARCHAR，好比記錄移

動設備平臺，只有兩個值：android，ios，那麼就可使用0表示android，1表示ios，這種

列必定要寫好註釋爲何不用ENUM呢？ENUM擴展困難，好比後來移動平臺又增長了一

個ipad，那豈不是懵逼了，而tinyint加個2就行，並且ENUM在代碼裏面處理起來特別奇怪，

是當成整形呢仍是字符串，各個語言不同。這種方式，必定要在數據庫註釋或者代碼裏面

寫明各個值的含義對於那些定長字符串，可使用char，好比郵編，老是5位對於那些長度未

知的字符串，使用varchar不要濫用bigint，好比記錄文章數目的表id字段，用int就好了，21億

篇文章上限夠了適當打破數據庫範式添加冗餘字段，避免查詢時的錶鏈接查詢的時候，確定int

 

類型比varchar快，由於整數的比較直接調用底層運算器就能夠實現，而字符串比較要逐個字符

比較。定長數據比變長數據查詢快，由於比較定長數據與數據之間的偏移是固定的，很容易計算

下一個數據的偏移。而變長數據則還須要多一步去查詢下一個數據的偏移量。不過。定長數據可

能會浪費更多的存儲空間。

 

大表拆分

 

對於那些數據量可能近期會超過500W或者增加很快的表，必定要提早作好垂直分表或者水平分表，

當數據量超過百萬之後，查詢速度會明顯降低。分庫分表儘可能在數據庫設計初期敲定方案，不然後

期會極大增長代碼複雜性並且不易更改。垂直分表是按照日期等外部變量進行分表，水平分表是按

照表中的某些字段關係，使用hash映射等分表。分庫分表的前提條件是在執行查詢語句以前，已經

知道須要查詢的數據可能會落在哪個分庫和哪個分表中。

 

優化查詢語句

 

這個纔是不少系統數據庫瓶頸的始做俑者。

 

請儘可能使用簡單的查詢，避免使用表連接請儘可能避免全表掃描，包括但不限於：where子句條件橫真

或爲空使用LIKE使用不等操做符（<>、!=）查詢含義is null的列在非索引列上使用or多條件查詢時，

請把簡單查詢條件或則索引列查詢置於前面請儘可能指定須要查詢的列，不要偷懶使用select *若是不

指定，一方面會返回多餘的數據，佔用寬帶等另外一方面MySQL執行查詢的時候，沒有字段時會先去

查詢表結構有哪些字段大些的查詢關鍵字比小寫快一點點使用子查詢會建立臨時表，會比連接（JOIN）

和聯合（UNION）稍慢在索引字段上查詢儘可能不要使用數據庫函數，不便於緩存查詢結果當只要一行數

據時，請使用LIMIT 1，若是數據過多，請適當設定LIMIT，分頁查詢千萬不要 ORDER BY RAND()，性

能極低。

 

上面是我總結的一些小tips，這些規則是死的，可是業務場景是活的，在實際使用的過程當中，好比數據統計，能夠適當犧牲性能換取便利。

 

添加緩存

 

使用redis等緩存，還有本地文件緩存等，能夠極大地減小數據庫查詢次數。緩存這個東西，必定要分析本身系統的數據特色，適當選擇。

 

對於一些經常使用的數據，好比配置信息等，能夠放在緩存中能夠在本地緩存數據庫的表結構緩存的數據必定要注意及時更新，還有設置有效期增長緩存務必會增長系統複雜性，必定要注意權衡