7000 字乾貨學習筆記，一天搞定MySQL

時間 2020-07-07

標籤乾貨學習筆記一天 1天搞定 mysql 欄目 MySQL 简体版

原文原文鏈接

MySQL數據庫簡介

MySQL近兩年一直穩居第二，隨時有可能超過Oracle計晉升爲第一名，由於MySQL的性能一直在被優化，同時安全機制也是逐漸成熟，更重要的是開源免費的。 php

MySQL是一種關係數據庫管理系統，關係數據庫將數據保存在不一樣的表中，而不是將全部數據放在一個大倉庫內，這樣就增長了速度並提升了靈活性。mysql

MySQL所使用的 SQL 語言是用於訪問數據庫的最經常使用標準化語言。MySQL 軟件採用了雙受權政策，分爲社區版和商業版，因爲其體積小、速度快、整體擁有成本低，尤爲是開放源碼這一特色，通常中小型網站的開發都選擇 MySQL 做爲網站數據庫。面試

若是不會安裝MySQL請移步：MySQL服務安裝sql

MySQL InnoDB存儲引擎

存儲引擎InnoDB是目前MySQL版本默認的存儲引擎，也是MySQL推薦使用的存儲引擎，是集高可靠性和高性能於一身的存儲引擎。
在MySQL5.7版本中，除非在配置文件中顯視指定default storage engine或者建立表時顯視使用engine=語句指定其它的存儲引擎，不然默認都是InnoDB。

InnoDB存儲引擎的優點：數據庫

DML語句支持事務功能，保證ACID特性
行級鎖的使用保證了高併發的屬性
InnoDB對有主鍵的表會依據主鍵優化查詢性能，也稱聚簇索引，將全部數據存儲在聚簇索引上以減小對主鍵查詢的IO消耗
爲保證數據的一致性，InnoDB還支持外鍵屬性，確保有外鍵約束的表之間不會有不一致的數據
當服務器硬件或者軟件故障致使MySQL重啓後，InnoDB會自動識別已經在故障以前提交的數據，並回退全部故障時未提交的數據，最大限度的保護數據不會丟失(crash recovery)

一、事物（Transaction）
二、MVCC（多版本併發控制）
三、行級鎖（Row-level Lock）
四、支持外鍵
五、ACSR（Auto Crrash safe Recovery）自動的故障安全恢復
六、支持熱備份

MySQL複製集羣原理與實戰

MySQL複製有兩種方法：

傳統方式：基於主庫的bin-log將日誌事件和事件位置複製到從庫，從庫再加以應用來達到主從同步的目的。
Gtid方式：global transaction identifiers是基於事務來複制數據，所以也就不依賴日誌文件位置，同時又能更好的保證主從庫數據一致性。

MySQL數據庫主從同步實戰過程安全

MySQL 主從同步架構中你不知道的「坑」（上）性能優化

MySQL 主從同步架構中你不知道的「坑」（下）bash

數據備份多種方式：

物理備份是指經過拷貝數據庫文件的方式完成備份，這種備份方式適用於數據庫很大，數據重要且須要快速恢復的數據庫
邏輯備份是指經過備份數據庫的邏輯結構（create database/table語句)和數據內容（insert語句或者文本文件）的方式完成備份。這種備份方式適用於數據庫不是很大，或者你須要對導出的文件作必定的修改，又或者是但願在另外的不一樣類型服務器上從新創建此數據庫的狀況
一般狀況下物理備份的速度要快於邏輯備份，另外物理備份的備份和恢復粒度範圍爲整個數據庫或者是單個文件。對單表是否有恢復能力取決於存儲引擎，好比在MyISAM存儲引擎下每一個表對應了獨立的文件，能夠單獨恢復；但對於InnoDB存儲引擎表來講，可能每一個表示對應了獨立的文件，也可能表使用了共享數據文件
物理備份一般要求在數據庫關閉的狀況下執行，但若是是在數據庫運行狀況下執行，則要求備份期間數據庫不能修改
邏輯備份的速度要慢於物理備份，是由於邏輯備份須要訪問數據庫並將內容轉化成邏輯備份須要的格式；一般輸出的備份文件大小也要比物理備份大；另外邏輯備份也不包含數據庫的配置文件和日誌文件內容；備份和恢復的粒度能夠是全部數據庫，也能夠是單個數據庫，也能夠是單個表；邏輯備份須要再數據庫運行的狀態下執行；它的執行工具能夠是mysqldump或者是select … into outfile兩種方式

送你一份生產數據庫備份方案：高逼格企業級MySQL數據庫備份方案服務器

MySQL數據庫物理備份方式：Xtrabackup實現數據的備份與恢復網絡

MySQL複製有多種類型：

異步複製：一個主庫，一個或多個從庫，數據異步同步到從庫。
同步複製：在MySQL Cluster中特有的複製方式。
半同步複製：在異步複製的基礎上，確保任何一個主庫上的事務在提交以前至少有一個從庫已經收到該事務並日志記錄下來。
延遲複製：在異步複製的基礎上，人爲設定主庫和從庫的數據同步延遲時間，即保證數據延遲至少是這個參數。
MySQL主從複製延遲解決方案：高可用數據庫主從複製延時的解決方案

MySQL高可用架構設計與實戰

先來了解一下MySQL高可用架構簡介：淺談MySQL集羣高可用架構

MySQL高可用方案：MySQL 同步複製及高可用方案總結

官方也提供一種高可用方案：官方工具｜MySQL Router 高可用原理與實戰

MHA

MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，該軟件由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點。
MHA Manager: 能夠單獨部署在一臺獨立的機器上管理多個master-slave集羣，也能夠部署在一臺slave節點上。
MHA Node: 行在每臺MySQL服務器上。
MHA Manager會定時探測集羣中的master節點，當master出現故障時，它能夠自動將最新數據的slave提高爲新的master，而後將全部其餘的slave從新指向新的master。整個故障轉移過程對應用程序徹底透明。

MHA高可用方案實戰：MySQL集羣高可用架構之MHA

MGR

Mysql Group Replication(MGR)是從5.7.17版本開始發佈的一個全新的高可用和高擴張的MySQL集羣服務。
高一致性，基於原生複製及paxos協議的組複製技術，以插件方式提供一致數據安全保證；
高容錯性，大多數服務正常就可繼續工做，自動不一樣節點檢測資源徵用衝突，按順序優先處理，內置動防腦裂機制；
高擴展性，自動添加移除節點，並更新組信息；
高靈活性，單主模式和多主模式。單主模式自動選主，全部更新操做在主進行；多主模式，全部server同時更新。

MySQL性能優化

史上最全的MySQL高性能優化實戰總結！

MySQL索引原理：MySQL 的索引是什麼？怎麼優化？

顧名思義，B-tree索引使用B-tree的數據結構存儲數據，不一樣的存儲引擎以不一樣的方式使用B-Tree索引，好比MyISAM使用前綴壓縮技術使得索引空間更小，而InnoDB則按照原數據格式存儲，且MyISAM索引在索引中記錄了對應數據的物理位置，而InnoDB則在索引中記錄了對應的主鍵數值。B-Tree一般意味着全部的值都是按順序存儲，而且每一個葉子頁到根的距離相同。
B-Tree索引驅使存儲引擎再也不經過全表掃描獲取數據，而是從索引的根節點開始查找，在根節點和中間節點都存放了指向下層節點的指針，經過比較節點頁的值和要查找值能夠找到合適的指針進入下層子節點，直到最下層的葉子節點，最終的結果就是要麼找到對應的值，要麼找不到對應的值。整個B-tree樹的深度和表的大小直接相關。
全鍵值匹配：和索引中的全部列都進行匹配，好比查找姓名爲zhang san，出生於1982-1-1的人
匹配最左前綴：和索引中的最左邊的列進行匹配，好比查找全部姓爲zhang的人
匹配列前綴：匹配索引最左邊列的開頭部分，好比查找全部以z開頭的姓名的人
匹配範圍值：匹配索引列的範圍區域值，好比查找姓在li和wang之間的人
精確匹配左邊列並範圍匹配右邊的列：好比查找全部姓爲Zhang，且名字以K開頭的人
只訪問索引的查詢：查詢結果徹底能夠經過索引得到，也叫作覆蓋索引，好比查找全部姓爲zhang的人的姓名

MySQL表分區介紹：一文完全搞懂MySQL分區

能夠容許在⼀個表⾥存儲更多的數據，突破磁盤限制或者⽂件系統限制。
對於從表⾥將過時或歷史的數據移除在表分區很容易實現，只要將對應的分區移除便可。
對某些查詢和修改語句來講，能夠⾃動將數據範圍縮⼩到⼀個或⼏個表分區上，優化語句執⾏效率。⽽且能夠經過顯示指定表分區來執⾏語句，⽐如 select * from temp partition(p1,p2) where store_id < 5;
表分區是將⼀個表的數據按照⼀定的規則⽔平劃分爲不一樣的邏輯塊，並分別進⾏物理存儲，這個規則就叫作分區函數，能夠有不一樣的分區規則。
MySQL5.7版本能夠經過show plugins語句查看當前MySQL是否⽀持表分區功能。
MySQL8.0版本移除了show plugins⾥對partition的顯示，但社區版本的表分區功能是默認開啓的。
但當表中含有主鍵或惟⼀鍵時，則每一個被⽤做分區函數的字段必須是表中惟⼀鍵和主鍵的所有或⼀部分，不然就⽆法建立分區表。

MySQL分庫分表

能不分就不分，1000萬之內的表，不建議分片，經過合適的索引，讀寫分離等方式，能夠很好的解決性能問題。
分片數量儘可能少，分片儘可能均勻分佈在多個DataHost上，由於一個查詢SQL跨分片越多，則整體性能越差，雖然要好於全部數據在一個分片的結果，只在必要的時候進行擴容，增長分片數量。
分片規則須要慎重選擇，分片規則的選擇，須要考慮數據的增加模式，數據的訪問模式，分片關聯性問題，以及分片擴容問題，最近的分片策略爲範圍分片，枚舉分片，一致性Hash分片，這幾種分片都有利於擴容。
儘可能不要在一個事務中的SQL跨越多個分片，分佈式事務一直是個很差處理的問題。
查詢條件儘可能優化，儘可能避免Select * 的方式，大量數據結果集下，會消耗大量帶寬和CPU資源，查詢儘可能避免返回大量結果集，而且儘可能爲頻繁使用的查詢語句創建索引。

數據庫分庫分表概述：數據庫分庫分表，什麼時候分？怎樣分？

Mysql分庫分表方案：MySQL 分庫分表方案，總結的很是好！

Mysql分庫分表的思路：解救 DBA—數據庫分庫分表思路及案例分析

MySQL數據庫讀寫分離高可用

海量數據的存儲和訪問成爲了系統設計的瓶頸問題，日益增加的業務數據，無疑對數據庫形成了至關大的負載，同時對於系統的穩定性和擴展性提出很高的要求。隨着時間和業務的發展，數據庫中的表會愈來愈多，表中的數據量也會愈來愈大，相應地，數據操做的開銷也會愈來愈大；另外，不管怎樣升級硬件資源，單臺服務器的資源（CPU、磁盤、內存、網絡IO、事務數、鏈接數）老是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。分表、分庫和讀寫分離能夠有效地減少單臺數據庫的壓力。

MySQL讀寫分離高可用架構實戰案例：

ProxySQL+Mysql實現數據庫讀寫分離實戰

Mysql+Mycat實現數據庫主從同步與讀寫分離

MySQL性能監控

MySQL性能監控的指標大致能夠分爲如下4大類：

查詢吞吐量
查詢延遲與錯誤
客戶端鏈接與錯誤
緩衝池利用率

對於MySQL性能監控，官方也提供了相關的服務插件：MySQL-Percona，下面簡單介紹一下插件的安裝

[root@db01 ~]# yum -y install php php-mysql
[root@db01 ~]# wget https://www.percona.com/downloads/percona-monitoring-plugins/percona-monitoring-plugins-1.1.8/binary/redhat/7/x86_64/percona-zabbix-templates-1.1.8-1.noarch.rpm
[root@db01 ~]# rpm -ivh percona-zabbix-templates-1.1.8-1.noarch.rpm
warning: percona-zabbix-templates-1.1.8-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
Preparing... ################################# [100%]
Updating / installing
...   1:percona-zabbix-templates-1.1.8-1 ################################# [100%]

Scripts are installed to /var/lib/zabbix/percona/scripts
Templates are installed to /var/lib/zabbix/percona/templates

最後，能夠配合其它監控工具來實現對MySQL的性能監控。

MySQL服務器配置插件：

修改php腳本鏈接MySQL的monitor@localhost用戶
修改MySQL的sock文件路徑

[root@db01 ~]# sed -i '30c $mysql_user = "monitor";' /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php
[root@db01 ~]# sed -i '31c $mysql_pass = "123456";' /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php
[root@db01 ~]# sed -i '33c $mysql_socket = "/tmp/mysql.sock";' /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php

測試是否可用（能夠從MySQL中獲取到監控值）

[root@db01 ~]# /usr/bin/php -q /var/lib/zabbix/percona/scripts/ss_get_mysql_stats.php --host localhost --items gg
gg:12

# 確保當前文件的 屬主 屬組 是zabbix，不然zabbix監控取值錯誤。
[root@db01 ~]# ll -sh /tmp/localhost-mysql_cacti_stats.txt
4.0K -rw-rw-r-- 1 zabbix zabbix 1.3K Dec 5 17:34 /tmp/localhost-mysql_cacti_stats.txt

移動zabbix-agent配置文件到 /etc/zabbix/zabbix_agentd.d/目錄

[root@db01 ~]# mv /var/lib/zabbix/percona/templates/userparameter_percona_mysql.conf /etc/zabbix/zabbix_agentd.d/
[root@db01 ~]# systemctl restart zabbix-agent.service

導入並配置Zabbix模板與主機：

默認模板監控時間爲 5分鐘（當前測試修改成 30s）同時也要修改Zabbix模板時間

# 若是要修改監控獲取值的時間不但要在zabbix面板修改取值時間，bash腳本也要修改。
[root@db01 scripts]# sed -n '/TIMEFLM/p' /var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh
TIMEFLM=`stat -c %Y /tmp/$HOST-mysql_cacti_stats.txt`
if [ `expr $TIMENOW - $TIMEFLM` -gt 300 ]; then  
# 這個 300 表明 300s 同時也要修改。

默認模板版本爲 2.0.9，沒法在4.0版本使用，能夠先從3.0版本導出，而後再導入4.0版本。

其實，在實際生產過程當中，仍是有相關的專業監控數據庫的第三方開源軟件的，民工哥以前也寫過相關的文章，今天發出來供你們參考：強大的開源企業級數據庫監控利器Lepus