數據庫的性能優化的一些思考

1，服務器目前的架構 cpu 內存 io 網絡

一主 -》 多從(14) 主服務器宕機 切換從服務器慢

監控指標 ：qps和tps (慢sql佔用cpu時間太長,每一個sql只能是一個cpu執行,qps超高形成阻塞)

併發量和cpu使用率 (鏈接數被佔滿，cpu資源耗盡出現宕機)

磁盤IO

網卡IO

大表(千萬行數據,文件10g數據,查詢條件複雜)

查詢慢容易產生慢sql，產生大量的磁盤IO，更改列會很慢，創建索引時間長，主從延遲大

ddl操做會長時間鎖表，形成主從延遲，正常數據會被阻塞，大量的連接超時

分庫分表：主鍵選擇 跨分區數據查詢和統計

數據歸檔：時間點的選擇(歷史數據的查詢作單獨的入口，分離冷熱數據，歷史數據的統計和計算數據作異步處理)

歸檔操做的方式選擇

大事務(關係型數據庫的特性，原子性操做，原子性 一致性 隔離性 持久性)

要麼所有成功要麼失敗回滾，

事務操做前和操做後完整性不能被破壞，

事務未提交以前對事務的操做不可見(未提交讀，已提交讀(默認隔離級別)，可重複讀(mysql默認)，可串行化)

事務執行完以後持久化到磁盤不會丟失

運行時間比較長，操做數據比較多的事務叫作大事務

鎖定的數據太多，形成大量的阻塞和鎖超時

回滾所需的時間比較長

執行時間比較長，主從同步延遲太大

 

避免一次處理太多數據(分批處理)

移除沒必要要的select操做

 

2，影響性能的幾個方面

硬件

服務器系統

存儲引擎(插件式的存儲引擎選擇)

myisam 不支持事務，表級鎖

innodb 事務，行級鎖 ACID特性

數據庫配置參數

表結構的設計和sql語句

3，硬件的影響

cpu 頻率和核數,

mysql單條sql沒法使用多個cpu，qps:每秒處理sql數量，核數比處理能力重要

內存大小

內存的io大於磁盤不少 熱數據 > 可用內存數據

myisam 把索引緩存在內存中，數據經過操做系統緩存

innodb 同時緩存 數據和索引到內存

讀減小磁盤io，寫減小磁盤io

磁盤IO和網絡資源

存儲大小，傳輸速度，訪問時間，主軸轉速，物理尺寸

RAID技術：磁盤冗餘隊列，小磁盤組成大磁盤，提供數據冗餘保持數據完整性

RAID0 沒有冗餘和數據修復能力，多個磁盤串聯在一塊兒，併發寫入，容量相加

RAID1 磁盤鏡像，生成數據備份鏡像，併發寫同時備份，磁盤冗餘，容量減小50%

RAID5 奇偶校驗磁盤陣列，任何數據失效均可以從奇偶校驗塊中重建

READ10 分片鏡像 RAID1+READ0

 

固態硬盤SSD， PCIE SSD 比機械盤有更好的隨機讀寫的性能，更好的支持併發，更容易損壞

SSD SATA接口 直接替換傳統磁盤，一樣支持RAID技術

PCI-E SSD 沒法使用SATA接口，須要獨特的驅動配置，貴性能更好

 

適用於大量隨機IO，解決單線程負載的IO瓶頸

網絡存儲NAS和SAN

SAN -》服務器-》SAN 經過光纖訪問服務器

緩存 大量順序讀寫 隨機讀寫慢

NAS 使用網絡鏈接，經過文件協議 NFS和SMB訪問

網絡設備 (延遲和帶寬)

高性能高代開網絡接口設備

多個網卡綁定增長可用性和帶寬

網絡隔離 內外網隔離 業務隔離

 

總結，64位架構運行在64位系統

併發高的場景cpu核數比頻率重要，cpu密集型和複雜sql頻率越高越好

選擇主辦能使用的最高內存，儘量的大

IO子系統 PCIe-》SSD-〉Raid10-》磁盤-〉SAN

3，服務器的影響

mysql比較常見的運行到linux，window對大小寫不敏感，強制使用小寫

window FreeBSD Solaris Linux

 

centos 參數優化

/etc/sysctl.conf

net.core.somaxconn=65535

net.core.netdev_max_backlog=65535

net.ipv4.tcp_max_syn_backlog=65535

 

net.ipv4.tcp_fin_timeout=10

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_tw_recycle=1

 

net.core.wmem_default=87380

net.core.wmem_max=16777216

net.core.rmem_default=87380

net.core.rmem_max=16777216

 

net.ipv4.tcp_keepalive_time=120

net.ipv4.tcp_keepalive_intvl=30

net.ipv4.tcp_keepalive_probes=3

 

kernel.shmmax=429497295

vm.swappiness=0

 

/etc/security/limit.conf

* soft nofile 65535

* hard nofile 65535

 

/sys/block/devname/queue/scheduler

磁盤調度策略

 

文件系統

windows (FAT NTFS)

linux(EXT3 EXT4 XFS)

 

4,mysql架構

插件式存儲引擎，數據處理和存儲相分離

cs結構

客戶端(java php c ODBC JDBC),負責鏈接處理，受權認證，安全等，一個鏈接智能化用到一個cpu，全部的操做都是在一個線程操做

服務層 鏈接管理()->查詢緩存-》查詢解析-〉查詢優化 全部跨存儲引擎的功能都在這一層

存儲引擎層 針對於表的，不這對庫文件

myisam： mysql5.5只前的默認存儲引擎，

系統表,臨時表(排序分組操做，數量超過必定大小，由查詢優化器創建臨時表)使用的存儲引擎。

MYD和MYI兩個文件存儲數據，frm存儲表結構。

表級別鎖，讀寫混合的併發性很差；

表修復check table tablename；repair table tablename；

全文索引(mysql5.7以前惟一原生支持全文索引的引擎)，對text和blog的前500字符的前綴索引

支持表數據壓縮(myisampack),壓縮表的只讀表不能插入和更新

mysql5.0以前單表最大4G(MAX_Rows AVG_ROW)LENGTH),mysql5.0以後最大256TB

使用場景：非事務應用，只讀類型的併發性好，空間類應用(空間函數 5.0以前的必選)

Innodb：mysql默認存儲引擎，表空間存儲數據,（innodb_file_per_table: on 獨立表空間 .ibd , off系統表空間 ibdataX)

.frm和表空間文件

系統表空間沒法簡單收縮文件大小形成磁盤碎片，獨立表空間使用optimize table命令重建表空間收縮文件系統

系統表空間產生IO瓶頸，獨立表空間能夠同時刷新多個文件數據，mysql5.6以後默認獨立表空間

frm存儲的是服務器層的數據字典跟引擎無關的，系統表空間存放引擎相關的數據字典，回滾段

事務型存儲引擎ACID，redolog和undolog實現；行級鎖，在存儲引擎層實現，服務層不可見

鎖(管理共享資源的併發訪問，實現事務隔離)，共享鎖(讀鎖)，獨佔鎖(寫鎖)

阻塞：等待其餘的鎖釋放資源，慢查詢產生大量的阻塞

死鎖：事務相互佔用資源，系統自動識別死鎖，並釋放佔用資源較少的事務，使得事務繼續運行

show engine innodb status ；//狀態檢測

除了5.7以前的空間應用和全文索引狀況都要默認innodb引擎

 

CSV存儲引擎 存儲文件.csv文件，一文件方式存儲，myisam和innodb是二進制文件存儲的

.frm表結構 .csv存儲表數據內容 .csm存儲表的元數據 數據量 表狀態等

全部的列不能是null，不支持索引，不適合作發表和在線處理數據，能夠直接對數據進行編輯

適合作數據交換中間表

Archive 以zlib對錶數據進行壓縮，佔用更少的磁盤IO和存儲空間，數據問價 .frm和.arz文件

只支持insert和select操做，行級鎖，專用的緩衝區，支持高併發插入，只支持自增ID創建索引

適合 日誌和數據採集的應用

memory引擎 數據存儲在內存中，表結構保持在磁盤，也叫HEAP引擎

支持HASH(默認)和BTREE索引，等於查詢時hash索引快，btree索引作範圍查找快

全部字段都是固定長度 varchar(10)=char(10)

不支持blog和text字段類型

表級鎖，併發性能有影響，max_heap_table_size決定最大表數據

 

系統自動建立:  tmp-table-size 或  max-heap-table-size 

1,超過限制使用myisam臨時表 2,未超過如今使用memory臨時表

主動建立： create temporary table

 

適用於映射表查找表，保存分析數據的中間表 緩存週期性聚合結果表

federated引擎 提供遠程訪問mysql服務器上表的功能,本地不存儲數據，本地保存表結構和遠程服務器的鏈接信息

默認mysql禁止使用，性能很差。

設置federated=1開啓;

適用於 手動統計分析查詢

 

存儲引擎選擇，沒有特殊需求innodb是最佳選擇

事務支持:innodb最穩定，select和insert 選myisam insert選archive

備份：innodb有在線熱備份方案，mysqldump不是熱備份(會加鎖的邏輯備份)

崩潰恢復 innodb比myisam好不少

特殊引擎特性需求

mysql服務器配置

mysql配置文件 my.conf

參數做用域 全局set global 參數=值

會話 set session 參數=值

內存相關參數：可以使用內存上限(單進程運行)

每一個sql鏈接的使用內存

(sort_buffer_size 須要排序的sql會分配這部份內存)

(join_buffer_size 每一個線程使用的鏈接緩衝區，每一個連表分配一個)

(read_buffer_size 讀緩衝區 全表掃描myisam時分配，4k的倍數)

(read_rnd_buffer_size 索引緩衝區)

緩存池分配的內存

innodb_buffer_poll_size 緩存索引和數據，延遲寫入(合併多個寫入一塊兒寫入磁盤)

總內存 - 單個線程內存*鏈接數 -系統保留內存 建議服務器內存的75%

key_buffer_size 主要是myisam用，緩存索引，數據依賴操做系統緩存

IO相關的配置參數：性能 安全 作平衡 貴啊

innodb：innodb_log_file_size * innodb_log_files_in_group = 事務日誌總大小

innodb_log_buffer_size 事務日誌緩衝區秒級持久化

innodb_flush_log_at_trx_commit 0秒級寫入chach並flush到磁盤

1每次事務提交都寫入cache並flush到磁盤

2每次都寫入cache，每秒flush到磁盤

innodb_flush_method=O_DIRECT 操做系統不緩存數據

innodb_file_per_table =1 innodb的表空間

innodb_foublewrite = 1 雙寫緩存，避免葉沒寫完整就寫到文件中

myisam：delay_key_write OFF ON ALL

安全相關配置：

expire_log_days 指定binlog自動清理的天數

max_allowed_packet 控制mysql可接收的包的大小

skip_name_resolve 禁用DNS查找

syadate_is_now 確保sysdate()返回肯定日期

read_only 禁止super全縣用戶的寫權限

skip_slave_start 禁止slave自動恢復

sql_mode 設置mysql使用的sql模式

(strict_trans_tables, no_engine_subtitution,no_zero_date,no_zero_in_date,only_full_group_by)

其餘配置的影響

sysc_binlog 默認爲0 ，操做系統決定何時刷新binlog;1，每次事務都會有寫binlog操做

tmp_table_size 和 max_heap_table_size 內存臨時表的大小，超過就會生產磁盤臨時表

max_connections 控制最大鏈接數

結構設計和sql優化

表的列太多，因爲插件式引擎設計，mysql的服務層和引擎層是分離的，在引擎層的api和服務器層須要緩存格式來拷貝數據，而後在服務器層解析轉換成各個列。

關聯太多的表 10個是極限

OLTP環境不恰當使用分區表

外鍵的使用 保證數據完整性，效率低，修改和備份時候，要檢查約束，額外的鎖的開銷

 

總結：數據庫結構設計 和 sql優化 > 數據庫的存儲引擎和參數配置 > 系統參數的優化 > 硬件的升級

 

 

5，mysql性能測試

基準測試 直接簡單，易於比較，評估服務器處理能力，不涉及邏輯處理

壓力測試 正式業務數據進行測試，得到真實的業務系統的壓力

指標：TPS QPS 響應時間(最大 最小平均 響應時間 各個時間百分比) 併發請求數量(同時操做的數量 不是同時存在的進程)

收集信息：cpu使用率 IO 網絡流量 狀態 計數器信息等

工具：ab，mysqlslap(mysql5.1以後自帶)，sysbench ,Super Smack

 

6，表結構設計對性能的影響

良好的數據庫邏輯設計和物理設計是數據庫良好性能的jichu

目標：減小數據的冗餘，避免數據的依賴維護異常，節約數據的存儲空間，提升查詢效率

步驟：需求分析(存儲需求，處理需求，安全性和完整性)

邏輯設計(設計數據的邏輯存儲結構，數據實體之間的邏輯關係，解決數據冗餘，維護數據異常)

物理設計(表結構的設計)

維護優化(根據實際業務狀況進行索引，存儲結構的優化)

 

表邏輯設計 範式+反範式結合 = 高性能

範式：...... 減小冗餘，體積小，更新快

查詢關聯表多，查詢效率低；索引優化更加困難

反範式化: 空間換時間，更加方便查詢條件的設計，提升查詢效率,減小關聯表，更好的索引優化(覆蓋索引等)

物理設計

命名規範：庫，表，字段的命名規範，不能用大小寫區分，可讀性，表意義的表達，完整單詞

存儲引擎：沒特殊要求就用innodb，上邊寫過各個引擎的使用場景

表字段：合適的數據類型

數字》日期〉二進制》字符 (字符的比較排序等是根據字符集排序規則相關的，數字二進制日期等不用二進制大小能夠直接比較)

同時佔用空間越小越好(數據處理以頁爲單位的 innodb是16k，列越小每頁的數據量就越多)

tinnyint 1字節 -128，128 0，255

smallint 2字節

mediuint 3字節

int 4字節

bigint 8字節

 

float 4字節

double 8個字節

decimal 每4字節存儲9個數字，小數點佔一個字節

 

varchar 變長字符串，只佔用必要的存儲空間

額外的字節存儲字符串長度，列的長度超過255須要兩個字節存儲字符串長度，最大就是65535長度，因此不可能用3個字節

使用最小符合需求的長度(改變長度會鎖表，5.7以後不超過255不會鎖表)

varchar(5)和varchar(200)性能比較，mysql在加載數據到內存中使用的是固定寬度，緩存和內存臨時表的時候消耗的內存比較多

適合存儲長度比較分散的數據，不多被更新的數據(字符長度變化，可能引發存儲頁的分裂,產生磁盤碎片)，多字節字符集

char 固定寬度字符串，末尾的空格會被過濾刪除，最大寬度255

適合存儲長度比較集中，長度短小的字符串，常常被更新的字符列

日期類型 datetime類型 以yyyy-mm-dd hh:mm:ss 存儲，與時區無關，佔用8個字節存儲空間

date 和 time 類型

timestamp類型 時間戳，顯示格式yyyy-mm-dd hh:mm:ss，只佔用4個字節，依賴時區，自動修改更新

存儲空間比字符串少，日期能夠對比，日期函數方便計算；不要用int來代替timestamp存儲時間，並無什麼好處

7，mysql架構設計

主從複製：分擔mysql的讀負載，高可用，災難恢復備份，經過二進制日誌同步數據，異步處理，有延遲

二進制日誌增量進行復制，不須要太多帶寬，基於行的複製在大批量修改時會帶來帶寬壓力

mysql的二進制日誌，慢查詢日誌，通用日誌屬於服務層日誌，innodb的重作日誌和回滾日誌屬於引擎層日誌

二進制日誌：記錄了mysql數據庫的修改事件，增刪改事件和表結構變化

binlog_format=STATEMENT 基於段的日誌格式，記錄sql和上下文信息，日誌量少，節約磁盤和網絡io

可是使用非肯定性函數，致使上下文信息沒法肯定的狀況時沒法複製的、

binlog_format=ROW 基於行的日誌格式 默認格式 官方推薦，記錄每行數據的修改

更加安全的複製，複製的效率高，下降主從延遲時間

日誌的量比較大，binlog_row_image = FULL | MINIMAL | NOBLOB

binlog_format=MIXED 混合行和段的日誌格式 系統根據sql內容必定的算法肯定

 

主從複製過程:

1,開啓主服務器二進制日誌，主服務器將寫入更新寫入二進制日誌

2,從服務器讀取主服務器二進制增量寫入到relay_log中，io線程，轉儲線程

3,從服務器從新執行relay_log的內容

基於日誌的複製創建過程：初始化從庫數據(mysqldump 等工具)-》啓動複製(指定 master 用戶 密碼 二進制文件 偏移量)

基於GTID的複製：GTID全局事務ID，每一個主庫上提交的事務生成惟一ID，從服務器會告訴主服務器已執行的事務的GTID值，主庫會告訴從哪些GTID事務沒有被執行。

故障處理麻煩，沒有skip衝突的操做

GTID = source_id:transsction_id

參考: https://www.jianshu.com/p/169315f2124a?utm_source=oschina-app

 

mysql5.7以後支持多主多從

一主多從 mysql5.7以前一直支持

配置簡單，

多個從庫分擔讀負載，分擔主庫的讀負載

不一樣的業務使用不一樣的從庫，不一樣的業務使用不一樣的索引

雙主複製 互爲主從

容易產生衝突，儘可能分開每一個庫操做的表

主備複製 高可用方案

一臺mysql只讀，作熱備份，主庫故障纔會切換成主服務器

一臺mysql作主服務器，切換後做爲備份服務器的從庫

主從延遲 主從延遲不可避免

主庫寫入二進制的時間(大事務)，控制事務的大小，分割成小事務

二進制的傳輸時間(日誌量，磁盤IO，網絡帶寬)，設置給予MIXED的日誌格式

從庫重放sql，單線程串行處理重放sql(主庫的併發寫入從庫變成串行),mysql5.6後支持單庫的多線程複製

mysql5,7支持邏輯時鐘的多線程複製

主從複製中斷

數據損壞丟失，主從的二進制日誌損壞

從庫數據被修改，形成數據衝突

不惟一的server_id,server_uuid

 

高可用 High Availability 縮短故障和系統維護的停機時間，提升可用性

服務器磁盤空間耗盡，性能糟糕的sql，表結構索引沒有優化，人爲操做失誤，主從故障等

創建完整的監控系統，備份數據的恢復測試，及時歸檔和清理不須要的數據

增長系統的冗餘，避免單點故障，主從切換故障轉移

 

單點故障

利用SUN共享存儲或DRDB磁盤鏡像解決mysql單點故障

多寫集羣(pxc)或NDB集羣解決單點故障

主從複製來解決單點故障

MMM(perl):監控管理mysql主主複製的拓撲，切換主備服務器的切換和故障轉移，提供讀寫虛擬ip

同一時間只有一臺主mysql對外服務，其餘的事只讀模式

監控主從中斷，延遲過大時，進程故障轉移

MHA(perl) : 監控主從複製的拓撲，切換主從服務器完成故障轉移

監控主服務器是否可用，不能夠就從衆多的從服務器選舉出一個作主服務器

讀寫分離 負載均衡

寫操做在主服務器進行，讀操做在多個從庫進行負載均衡

程序實現讀寫分離，更靈活控制鏈接主從數據庫，直接鏈接效率高，可是增長工做量程序複雜，人爲控制容易出錯

讀寫中間件實現 mysql-proxy maxScale 根據語法分析解析出時讀操做仍是寫操做，存儲過程等直接算主操做，多程序透明，節約開發成本；可是增長了中間層，對查詢效率損耗很大，對延遲敏感的業務沒法在主庫執行

負載均衡：程序輪循，軟件(LVS Haproxy MaxScale) ，硬件F5等

 

8，索引查詢的優化

索引做用是快速查找到須要的數據(太多，太少的索引都會損耗性能)，mysql在存儲引擎層實現的索引，不一樣的存儲引擎索引的使用是不同的；減小存儲引擎掃描的數據量(innodb的每次io以頁爲單位默認16k)，幫助排序避免臨時表的產生，把隨機i 哦轉變爲順序io。

同時，索引會增長更新插入成本，要維護索引和統計信息，innodb引入了插入緩存把屢次插入操做合併操做；同時mysql的查詢優化器會分析索引選擇合適的索引，太多的索引也會增長查詢優化器的時間。

 

b-tree索引：以B+樹的結構存儲數據，是一個平衡查找樹。能加快查找數據的速度，更加合適範圍查找

每一個葉子到根的距離是相同的，每一個節點按照鍵值的大小順序存放

全值匹配查詢，匹配最左前綴查詢，匹配列前綴的查詢，匹配範圍值的查詢，精確匹配左前列並範圍匹配下一列，索引覆蓋，order by 排等；

not in, != ,<> 等否認查詢在b-tree不會用到索引(網上查的待求證 跟引擎有關)

索引列上不能使用表達式和函數

innodb 索引最大大小不能超過767個字節，myisam是1000個字節，大字符串要使用前綴索引，前綴索引就要考慮到索引的選擇性

聯合索引 mysql5.0以前一條sql只能使用到一個列上的索引；mysql5.0以後引入了索引合併，能夠合併多個列上的索引進行過濾，可是須要更多的內存和磁盤IO來緩存這些索引獲取的數據，聯合索引更好；

列的順序:常常被使用的列優先，選擇性高的列優先，寬度小的列優先

覆蓋索引 除了where條件以外，能夠直接經過索引獲取查詢的數據，也就不必去讀取數據行的數據了，避免innodb主鍵索引的二次查詢，避免myisam的系統調用

 

hash索引：基於hash表實現，只有查詢精確匹配到hash索引全部的列纔會用到索引，存儲引擎會爲每一行計算hash碼，hash索引存儲的就是hash碼，就是說查找會很快，必須二次查找；存儲順序是按照hash碼的大小存儲的，不能用於排序、範圍查找等；hash衝突

 

索引優化排序：經過索引掃描數據，索引的順序和order by字段徹底一致，排序方向也要徹底一致，連表查詢必須在主表中

索引優化鎖：減小鎖定的行數量，加快處理速度，加快行釋放的速度

 

刪除重複和冗餘的索引，查找不會被使用的索引，更新索引的統計信息，減小索引碎片(analyze table table_name, optimize table會鎖表)

 

9，sql查詢的優化

獲取性能有問題的sql：經過用戶反饋，慢日誌獲取，實時獲取性能有問題的sql

慢日誌 開銷主要是磁盤的IO和磁盤存儲空間

慢查詢開啓 slow_query_log

慢查詢日誌存儲路徑 slow_query_log_file

慢查詢日誌sql時間伐值 long_query_time

是否記錄未使用索引的sql log_queries_not_using_indexes

mysqldumpslow ，pt-query-digest慢日誌分析工具

實時獲取有問題的sql show processlist

infomation_schema 數據庫下的processlist表:SELECT user, host, time, command, time FROM [mysql|information_schema].processlist WHERE user = 'me' and state IS NOT NULL;

 

mysql的執行sql的生命週期分析

客戶端經過mysql的接口發送sql給服務器

這個影響微乎其微

 

服務器檢查查詢緩存是否命中該sql，命中則直接返回結果

打開查詢緩存，優先查詢緩存是否命中，經過一個大小寫敏感的hash查找實現，hash是全值匹配，因此sql必須徹底同樣，每次更新查詢緩存涉及的表時緩存都會被刷新，並且在緩存查詢是否命中時候會對緩存加鎖，在併發高和讀寫太頻繁的系統中極可能是下降查詢處理效率

query_cache_type = ON | OFF | DEMAND

query_cache_size 查詢緩存內存大小1024 * n

query_cache_limit 查詢緩存可存儲的最大值

query_cache_wlock_invalidate 數據表鎖住是否返回緩存中的數據 默認關閉

query_cache_min_res_unit 查詢緩存分配的內存最小單位

在sql上加sql_no_cache 不去查詢緩存

 

服務器對sql進行解析，預處理，優化器生成執行計劃

mysql的解析器經過關鍵字對mysql進行語句解析，使用mysql的語法規則和解析查詢，生成一顆解析樹

預處理是進一步檢查解析樹是否合法(查詢中涉及的表和數據列是否存在，名字別名歧義等)

查詢優化器生成查詢計劃，一條sql可用有不少執行方式，優化器會對每種執行方式存儲引擎提供的統計信息進行比較，找到成本最低的計劃；可能從新定義表的關聯順序，將外鏈接轉化爲內鏈接，等價變換，將表達式轉換爲常數表達式，子查詢轉換爲關聯表

索引太多會致使優化器耗時太多；

存儲引擎提供的統計信息不許確、執行計劃的成本骨斷可能並非實際執行計劃的成本，服務層並不知道存儲層的全部信息，那些數據是在內存中仍是磁盤上，那些數據是順序讀仍是隨機讀，就會錯誤的選擇讀區數據少的執行計劃

優化器認爲的最優結果可能不是想要的(執行時間，資源利用最少)

優化器不會考慮併發問題，也就是鎖的問題對執行的影響

優化器會基於一些固定的規則生成執行計劃，不會考慮執行成本

 

根據執行計劃，調用引擎api查詢數據

這個影響微乎其微

返回客戶端結果

這個影響微乎其微

 

獲取sql執行各個階段的時間 profile(官方要廢棄) performance_schema(mysql5.5官方推薦的性能分析存儲引擎)

set profile = 1

執行sql

show profiles;

show profile for query N;

show profile cpu for query N;

...

 

開啓performance_schema 會記錄全部sql的階段執行時間監控

update `setup_instruments` SET enabled='YES' where NAME like 'stage&';

update `setup_consumers` SET enabled='YES' where NAME like 'event%';

sql執行優化

大表的數據修改要分批次處理，中間有間隔時間

大表結構的修改(表中的字段類型和寬度)會鎖表，先從從服務器修改，再主從切換，再修改老的主服務器再切換回來；

(pt-online-change-schamel)

not in 和 <> 等優化 ，使用連表等方式重寫sql

使用匯總表優化查詢

 

10，分庫分表

分擔數據庫的讀負載，可用作主從讀寫分離；數據量激增，數據庫的性能急劇降低，可用把服務器拆分

把一個實例的多個庫分到不一樣的數據庫

把一個實例中一個庫中不一樣的表拆分到多個庫

表水平拆分到不一樣的實例中

分區鍵的選擇，儘可能避免跨分片查詢發生，儘量平均分配數據到分片中，熱數據也要平均

分區鍵的hash值取模來分片，範圍分片，分區鍵和分片的映射表來分配數據

redis生成全局id並緩存

 

11，數據庫監控

數據庫的穩定性決定系統的穩定性，監控軟件有nagios和zabbix等。

可用性聯通監控 mysqladmin -umonitor_user -p -h ping

telnet ip db_port

代碼模擬真實應用鏈接數據庫

監控數據庫鏈接數

數據庫性能監控 QPS和TPS

 

數據庫的併發數量監控

 

數據庫的innodb的阻塞監控

 

主從複製的監控

pt-table-checksum