歷時七天，史上最強MySQL優化總結，今後優化So Easy！

1、概述

1. 爲何要優化

• 一個應用吞吐量瓶頸每每出如今數據庫的處理速度上
• 隨着應用程序的使用，數據庫數據逐漸增多,數據庫處理壓力逐漸增大
• 關係型數據庫的數據是存放在磁盤上的，讀寫速度較慢(與內存中的數據相比)

2. 如何優化

• 表、字段的設計階段,考量更優的存儲和計算
• 數據庫自身提供的優化功能，如索引
• 橫向擴展，主從複製、讀寫分離、負載均衡和高可用
• 典型SQL語句優化(收效甚微)

2、字段設計

1. 典型方案

①. 對精度有要求

• decimal
• 小數轉整數

②. 儘可能使用整數表示字符串（IP）

• inet_ aton("ip' )
• inet_ ntoa(num)

③. 儘量使用not null

• nuI數值的計算邏輯比較複雜

④. 定長和非定長的選擇

• 較長的數字數據可使用decimal
• char爲定長(超過長度的內容將被截掉)， varchar爲非定長，text對內容 長度的保存額外保存而varchar對長度的保存佔用數據空間

⑤. 字段數不要過多字段註釋是必要的、字段命名見名思意、能夠預留字段以備擴展

2. 範式

①. 第一範式：段原子性(關係型數據庫有列的念，默認就符合了)

②. 第二範式：消除對主鍵的部分依賴(由於主鍵可能不止一個)；使用一 個與業務無關的字段做爲主鍵

③. 第三範式：消除對主鍵的傳遞依賴；高內聚, 如商品表可分爲商品簡略信息表和商品詳情表兩張表

3、存儲引擎的選擇（MyISAM和Innodb）

1. 功能差別

Innodb支持事務、 行級鎖定、外健

2. 存儲差別

①. 存儲方式：MyISAM的數據和索弓 |是分開存儲的(.MYI.MYD) ， 而Innodb是存在一塊兒的(.frm)

②. 表可移動性：能夠經過移動表對應的MYI和MYD可以實現表的移動，而Innodb還有 額外的關聯文件

③. 碎片空間：MyISAM刪除數據時會產生碎片空間(佔用表文件空間)，須要按期經過optimizetable table-name手動優化。而Innodb不會。

④. 有序存儲：Innodb插入數據時按照主鍵有序來插入。所以表中數據默認按主鍵有序(耗費寫入時間，由於須要在b+ tree中查找插入點，但查找效率高)

3. 選擇差別

①. 讀多寫少用MyISAM：新聞、博客網站

②. 讀多寫也多用Innodb：

• 支持事務/外鍵，保證數據-致性、完整性
• 併發能力強(行鎖)

4、索引

1. 什麼是索引

從數據中提取的具備標識性的關鍵字，而且有到對應數據的映射關係

2. 類型

①. 主鍵索引primary key：要求關鍵字惟一且不爲null

②. 普通索引key：符合索引僅按照第一字段有序

③. 惟一索引unique key：要求關鍵字惟一

④. 全文索引fulltext key (不支持中文)

3. 索引管理語法

①. 查看索引

• show create table student
• desc student

②. 創建索引

• 建立時指定，如first. name varchar(1 6),last name(1 6) , key name(first_ name,last_ name)
• 更改表結構：alter table student add key/unique key/primary key/ultext key key. name(first_ name,last_ name)

③. 刪除索引

• alter table student drop key key_ name
• 若是刪除的是主鍵索引，而且主鍵自增加，則須要alter modify先取消自增加再刪除

4. 執行計劃explain

分析SQL執行是否用到了索引，用到了什麼索引

5. 索引使用的場景

• where：若是查找字段都創建了索引，則會索引覆蓋
• order by：若是排序字段創建了索引，而索引又是有序排列的，直接根據索引拿對應數據便可，與讀取查詢出來的全部數據再排序相比效率很高
• join：若是join on的條件字段創建了索引，查找會變得高效
• 索引覆蓋：直接對索引作查找，而不去讀取數據

6. 語法細節

即便創建了索引，有些場景也不必定使用

• where id+1 = ?建議寫成where id = ?-1，即保證索弓|字段的獨立出現
• like語句不要在關鍵字前模糊匹配，即"%keyword不會使用索引，而"keyword% 會使用索引
• or關鍵兩邊條件字段都創建索引時纔會使用索引，只要有一邊不是就會作全表掃描
• 狀態值。像性別這樣的狀態值，-個關鍵字對應不少條數據，會認爲使用索引比全表掃描效率還低

7. 索引的存儲結構

• btree：搜索多叉樹：結點內關鍵字有序排列，關鍵字之間有一個指針,查找效率log(nodeSize,N)，其中nodeSize指一 個結點內關鍵字數量 (這取決於關鍵字長度和結點大小)

• b+ tree：由btree升級而來，數據和關鍵字存在一塊空間，省去了由關鍵字到數據的映射找數據存放地的時間

5、查詢緩存

1. 將select查詢結果緩存起來，key爲SQL語句,value爲查詢結果

若是SQL功能同樣，但只是多個空格或略微改動都會致使key的不匹配

2. 客戶端開啓

query. cache. _type
複製代碼

• 0-不開啓
• 1-開啓，默認緩存每條select,針對某個sq不緩存: select sql-no-cache
• 2-開啓，默認都不緩存,經過select sql-cache制定緩存哪-個條

3. 客戶端設置緩存大小

query_ cache .size
複製代碼

4. 重蛋緩存

reset query cache
複製代碼

5. 緩存失效

日對數據表的改動會致使基 於該數據表的全部緩存失效(表層面的管理)

6、分區

1. 默認狀況下一張表對應一組存儲文件，但當數據量較大時(一般千萬條級別)須要將數據分到多組存儲文件，保證單個文件的處理效率

2. partition by分區函數(分區字段)(分區邏輯)

• hash-分區字段爲整型
• key-分區字段爲字符串
• range-基於比較，只支持less than
• list-基於狀態值

3. 分區管理

• 建立時分區：create table article0 partition by key(title) partitions 10
• 修改表結構：alter table article add partition(分區邏輯)

4. 分區字段應選擇經常使用的檢素字段，不然分區意義不大

7、水平分割和垂直分割

1. 水平

多張結構相同的表存儲同一類型數據

單獨一張表保證id惟一性

2. 垂直

分割字段到多張表，這些表記錄是一對應關係

8、集羣

1. 主從複製

①. 首先手動將slave和master同步一下

• stop slave
• master導出數據到slave執行一遍
• show master status with read lock記錄File和Position
• 到slave.上change master to

②. start slave查看Slave_ IO_ Running和Slave_ SQL_ _Running,必須都爲YES

③. master可讀可寫，但slave只能讀，不然主從複製會失效須要從新手動同步

④. mysqlreplicate快速配置主從複製

2. 讀寫分離(基於主從複製)

①. 使用原stcConecton

WriteDatabase提供寫鏈接

ReadDatabase提供讀鏈接

②. 藉助Sping AOP和Aspec實現數據源動態切換

• RoutingDataSourcelmpl extends AbstractRoutingDataSource,重寫determineDatasource,注入到SqISessionFactory, 配置defaultTargetDatasource和targetDatasource (根據determineDatasource的返回值選擇 具體數據源value-ref)

• DatasourceAspect切面組件，配置切入點@Pointcut aspect0 (全部DAO類的全部方法)，配置前置加強@Before(" aspect0") before(Joinpoint point)， 經過point.getSignature.getName獲取方法名，與METHOD TYPE MAP的前綴集合比對，將write/read設置到當前線程上(也是接下來要執行DAO方法的線程，前置加強將其攔截下來了)

• DatasourceHandler,使用ThreadLocal在前置通知中將方法要使用的數據源綁定到執行該方法的線程上，執行方法要獲取數據源時再根據當前線程獲取

3. 負載均衡

算法

• 輪詢
• 加權輪詢
• 依據負載狀況

4. 高可用

爲單機服務提供一個冗餘機

• 心跳檢測
• 虛IP
• 主從複製

9、典型SQL

1. 線上DDL

爲了不長時間表級鎖定

• copy策略,逐行復制，記錄複製期間舊錶SQL日誌從新執行
• mysq|5.6 online ddl,大大縮短鎖定時間

2. 批量導入

①. 先禁用索引和約束,導入以後統一創建

②. 避免逐條事務

innodb爲了保證一致性，默認爲每條SQL加事務(也是要耗費時間的)，批量導入前應手動創建事務，導入完畢後手動提交事務。

3. limit offset,rows

避兔較大的offset (較大頁碼數)

offset用來跳過數據，徹底能夠用過濾篩選數據，而不是查出來以後再經過offset跳過

4. select *

儘可能查詢所需字段,減小網絡傳輸延時(影響不大)

5. order by rand（）

會爲每條數據生成一個隨機數最後根據隨機數排序，可使用應用程序生成隨機主鍵代替

6. limit 1

若是肯定了僅僅檢索一條數據，建議都加上limit 1

10、慢查詢日誌

1. 定位查詢效率較低的SQL,針對性地作優化

2. 配置項

• 開啓slow_ query. log
• 臨界時間long_ query. time

3. 慢查詢日誌會本身記錄超過臨界時間的SQL，並保存在datadir下的xxx-slow.log中

11、Profile

1. 自動記錄每條SQL的執行時間和具體某個SQL的詳細步驟花費的時間

2. 配置項日

開啓profiling

3. 查看日誌信息show profiles

4. 查看具體SQL的詳細步驟花費的時間日

show profiles for query Query_ ID
複製代碼

12、典型的服務器配置

1. max_ connections, 最大客戶端鏈接數

2. table_ open_ cache, 表文件緩存句柄數，加快表文件的讀寫

3. key_ buffer. _size, 索引緩存大小

4. innodb_ buffer. pool size, innodb的緩衝池大小，實現innodb各類功能的前提

5. innodb_ file_ per_ table,每一個表一個ibd文件， 不然innodb共享 表空間

十3、壓測工具MySQLSlap

1. 自動生成sq|並執行來測試性能

myqslap -a-to-generate sql -root -root
複製代碼

2. 併發測試

mysqlslap --auto-generate-sql --concurrency= 100 -uroot -proot,模擬100個客戶端執行sql

3. 多輪測試，反應平均狀況

mysqlslap --auto-generate-sql --concurrency= 100 --interations=3 -uroot -proot,模擬100個客戶端執行sql.執行3輪

4. 存儲引擎測試

• --engine=innodb：mysqlslap --auto-generate-sql --concurrency= 100 --interations=3 -- engine-innodb -uroot -proot,模擬100個客戶端執行sql.執行3輪，innodb的處理性能

• -- engine= myisam：mysqlslap -- auto-generate-sql --concurrency= 100 --interations=3 --engine-innodb -uroot -proot,模擬100個客戶端執行sql.執行3輪，myisam的處理性能