一 主從故障怎么解決

1.登錄從庫(kù)

1、執(zhí)行stop slave;停止主從同步

2、然后set global sql_slave_skip_counter = 1;跳過(guò)一步錯(cuò)誤

3、最后執(zhí)行 start slave;并查看主從同步狀態(tài)

2.需要重新進(jìn)行主從同步操作步驟如下

進(jìn)入主庫(kù)

1、進(jìn)行全備數(shù)據(jù)庫(kù)并刷新binlog,查看主庫(kù)此的狀態(tài)

2、恢復(fù)全備文件到從庫(kù)，然后執(zhí)行change master

3、開(kāi)啟主從同步start slave;并查看主從同步狀態(tài)

二.怎么監(jiān)控主從是否故障

mysql -uroot -ppassowrd -e "show slave status\G" |grep -E "Slave_IO_Running|Slave_SQL_Running"|awk '{print $2}'|grep -c Yes

通過(guò)判斷Yes的個(gè)數(shù)來(lái)監(jiān)控主從復(fù)制狀態(tài)，正常情況等于2

三.全備、增備、冷備、熱備概念

全備：數(shù)據(jù)庫(kù)所有數(shù)據(jù)的一次完整備份，也就是備份當(dāng)前數(shù)據(jù)庫(kù)的所有數(shù)據(jù)

增備：就在上次備份的基礎(chǔ)上備份到現(xiàn)在所有新增的數(shù)據(jù)

冷備：停止服務(wù)的基礎(chǔ)上進(jìn)行備份操作

熱備：實(shí)行在線進(jìn)行備份操作，不影響數(shù)據(jù)庫(kù)的正常運(yùn)行

全備在企業(yè)中基本上是每周或天一次，其它時(shí)間是進(jìn)行增量備份

熱備使用的情況是有兩臺(tái)數(shù)據(jù)庫(kù)在同時(shí)提供服務(wù)的情況，針對(duì)歸檔模式的數(shù)據(jù)庫(kù)

冷備使用情況有企業(yè)初期，數(shù)據(jù)量不大且服務(wù)器數(shù)量不多，可能會(huì)執(zhí)行某些庫(kù)、表結(jié)構(gòu)等重大操作時(shí)

四.mysql主從復(fù)制原理流程

(1)、復(fù)制基本原理流程

1. 主：binlog線程——記錄下所有改變了數(shù)據(jù)庫(kù)數(shù)據(jù)的語(yǔ)句，放進(jìn)master上的binlog中；

2. 從：io線程——在使用start slave 之后，負(fù)責(zé)從master上拉取 binlog 內(nèi)容，放進(jìn) 自己的relay log中；

3. 從：sql執(zhí)行線程——執(zhí)行relay log中的語(yǔ)句；

(2)、MySQL復(fù)制的線程有幾個(gè)及之間的關(guān)聯(lián)

MySQL 的復(fù)制是基于如下 3 個(gè)線程的交互（ 多線程復(fù)制里面應(yīng)該是 4 類(lèi)線程）：

1. Master 上面的 binlog dump 線程，該線程負(fù)責(zé)將 master 的 binlog event 傳到slave；
2. Slave 上面的 IO 線程，該線程負(fù)責(zé)接收 Master 傳過(guò)來(lái)的 binlog，并寫(xiě)入 relay log；
3. Slave 上面的 SQL 線程，該線程負(fù)責(zé)讀取 relay log 并執(zhí)行；
4. 如果是多線程復(fù)制，無(wú)論是 5.6 庫(kù)級(jí)別的假多線程還是 MariaDB 或者 5.7 的真正的多線程復(fù)制， SQL 線程只做 coordinator，只負(fù)責(zé)把 relay log 中的 binlog讀出來(lái)然后交給 worker 線程， woker 線程負(fù)責(zé)具體 binlog event 的執(zhí)行；
   (3)、MySQL如何保證復(fù)制過(guò)程中數(shù)據(jù)一致性及減少數(shù)據(jù)同步延時(shí)

一致性主要有以下幾個(gè)方面：

1.在 MySQL5.5 以及之前， slave 的 SQL 線程執(zhí)行的 relay log 的位置只能保存在文件（ relay-log.info）里面，并且該文件默認(rèn)每執(zhí)行 10000 次事務(wù)做一次同步到磁盤(pán)， 這意味著 slave 意外 crash 重啟時(shí)， SQL 線程執(zhí)行到的位置和數(shù)據(jù)庫(kù)的數(shù)據(jù)是不一致的，將導(dǎo)致復(fù)制報(bào)錯(cuò)，如果不重搭復(fù)制，則有可能會(huì)
導(dǎo)致數(shù)據(jù)不一致。 MySQL 5.6 引入?yún)?shù) relay_log_info_repository，將該參數(shù)設(shè)置為 TABLE 時(shí)， MySQL 將 SQL 線程執(zhí)行到的位置存到mysql.slave_relay_log_info 表，這樣更新該表的位置和 SQL 線程執(zhí)行的用戶事務(wù)綁定成一個(gè)事務(wù)，這樣 slave 意外宕機(jī)后， slave 通過(guò) innodb 的崩潰
恢復(fù)可以把 SQL 線程執(zhí)行到的位置和用戶事務(wù)恢復(fù)到一致性的狀態(tài)。

2. MySQL 5.6 引入 GTID 復(fù)制，每個(gè) GTID 對(duì)應(yīng)的事務(wù)在每個(gè)實(shí)例上面最多執(zhí)行一次， 這極大地提高了復(fù)制的數(shù)據(jù)一致性；
3. MySQL 5.5 引入半同步復(fù)制， 用戶安裝半同步復(fù)制插件并且開(kāi)啟參數(shù)后，設(shè)置超時(shí)時(shí)間，可保證在超時(shí)時(shí)間內(nèi)如果 binlog 不傳到 slave 上面，那么用戶提交事務(wù)時(shí)不會(huì)返回，直到超時(shí)后切成異步復(fù)制，但是如果切成異步之前用戶線程提交時(shí)在 master 上面等待的時(shí)候，事務(wù)已經(jīng)提交，該事務(wù)對(duì) master
   上面的其他 session 是可見(jiàn)的，如果這時(shí) master 宕機(jī)，那么到 slave 上面該事務(wù)又不可見(jiàn)了，該問(wèn)題直到 5.7 才解決；
4. MySQL 5.7 引入無(wú)損半同步復(fù)制，引入?yún)?rpl_semi_sync_master_wait_point，該參數(shù)默認(rèn)為 after_sync，指的是在切成半同步之前，事務(wù)不提交，而是接收到 slave 的 ACK 確認(rèn)之后才提交該事務(wù)，從此，復(fù)制真正可以做到無(wú)損的了。
   5.可以再說(shuō)一下 5.7 的無(wú)損復(fù)制情況下， master 意外宕機(jī)，重啟后發(fā)現(xiàn)有 binlog沒(méi)傳到 slave 上面，這部分 binlog 怎么辦？？？分 2 種情況討論， 1 宕機(jī)時(shí)已經(jīng)切成異步了， 2 是宕機(jī)時(shí)還沒(méi)切成異步？？？ 這個(gè)怎么判斷宕機(jī)時(shí)有沒(méi)有切成異步呢？？？ 分別怎么處理？？？
   延時(shí)性：

5.5 是單線程復(fù)制， 5.6 是多庫(kù)復(fù)制（對(duì)于單庫(kù)或者單表的并發(fā)操作是沒(méi)用的）， 5.7 是真正意義的多線程復(fù)制，它的原理是基于 group commit， 只要
master 上面的事務(wù)是 group commit 的，那 slave 上面也可以通過(guò)多個(gè) worker線程去并發(fā)執(zhí)行。 和 MairaDB10.0.0.5 引入多線程復(fù)制的原理基本一樣。

五.mysqldump和xtrabackup實(shí)現(xiàn)原理

1.dump

mysqldump 屬于邏輯備份。加入--single-transaction 選項(xiàng)可以進(jìn)行一致性備份。后臺(tái)進(jìn)程會(huì)先設(shè)置 session 的事務(wù)隔離級(jí)別為 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)，之后顯式開(kāi)啟一個(gè)事務(wù)(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，這樣就保證了該事務(wù)里讀到的數(shù)據(jù)都是事務(wù)事務(wù)時(shí)候的快照。之后再把表的數(shù)據(jù)讀取出來(lái)。 如果加上--master-data=1 的話，在剛開(kāi)始的時(shí)候還會(huì)加一個(gè)數(shù)據(jù)庫(kù)的讀鎖(FLUSH TABLES WITH READ LOCK),等開(kāi)啟事務(wù)后，再記錄下數(shù)據(jù)庫(kù)此時(shí) binlog 的位置(showmaster status)，馬上解鎖，再讀取表的數(shù)據(jù)。等所有的數(shù)據(jù)都已經(jīng)導(dǎo)完，就可以結(jié)束事務(wù)

2.Xtrabackup:

xtrabackup 屬于物理備份，直接拷貝表空間文件，同時(shí)不斷掃描產(chǎn)生的 redo 日志并保存下來(lái)。最后完成 innodb 的備份后，會(huì)做一個(gè) flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作會(huì)丟數(shù)據(jù))，確保所有的 redo log 都已經(jīng)落盤(pán)(涉及到事務(wù)的兩階段提交概念，因?yàn)?xtrabackup 并不拷貝 binlog，所以必須保證所有的 redo log 都落盤(pán)，否則可能會(huì)丟最后一組提交事務(wù)的數(shù)據(jù))。這個(gè)時(shí)間點(diǎn)就是 innodb 完成備份的時(shí)間點(diǎn)，數(shù)據(jù)文件雖然不是一致性的，但是有這段時(shí)間的 redo 就可以讓數(shù)據(jù)文件達(dá)到一致性(恢復(fù)的時(shí)候做的事情)。然后還需要 flush tables with read lock，把 myisam 等其他引擎的表給備份出來(lái)，備份完后解鎖。 這樣就做到了完美的熱備。

六.mysql事務(wù)四大特性

1.原子性：不可分割的操作單元，事務(wù)中所有操作，要么全部成功；要么撤回到執(zhí)行事務(wù)之前的狀態(tài)

2.一致性：如果在執(zhí)行事務(wù)之前數(shù)據(jù)庫(kù)是一致的，那么在執(zhí)行事務(wù)之后數(shù)據(jù)庫(kù)也還是一致的；

3.隔離性：事務(wù)操作之間彼此獨(dú)立和透明互不影響。事務(wù)獨(dú)立運(yùn)行。這通常使用鎖來(lái)實(shí)現(xiàn)。一個(gè)事務(wù)處理后的結(jié)果，影響了其他事務(wù)，那么其他事務(wù)會(huì)撤回。事務(wù)的100%隔離，需要犧牲速度。

4.持久性：事務(wù)一旦提交，其結(jié)果就是永久的。即便發(fā)生系統(tǒng)故障，也能恢復(fù)。

七.索引

數(shù)據(jù)庫(kù)索引，是數(shù)據(jù)庫(kù)管理系統(tǒng)中一個(gè)排序的數(shù)據(jù)結(jié)構(gòu)，以協(xié)助快速查詢(xún)、更新數(shù)據(jù)庫(kù)表中數(shù)據(jù)。索引的實(shí)現(xiàn)通常使用 B_TREE。B_TREE 索引加速了數(shù)據(jù)訪問(wèn)，因?yàn)榇鎯?chǔ)引擎不會(huì)再去掃描整張表得到需要的數(shù)據(jù)；相反，它從根節(jié)點(diǎn)開(kāi)始，根節(jié)點(diǎn)保存了子節(jié)點(diǎn)的指針，存儲(chǔ)引擎會(huì)根據(jù)指針快速尋找數(shù)據(jù)。

MySQL數(shù)據(jù)庫(kù)的四類(lèi)索引:

1.index ---- 普通索引,數(shù)據(jù)可以重復(fù)，沒(méi)有任何限制。

2.unique ---- 唯一索引,要求索引列的值必須唯一，但允許有空值；如果是組合索引，那么列值的組合必須唯一。

3.primary key ---- 主鍵索引,是一種特殊的唯一索引，一個(gè)表只能有一個(gè)主鍵，不允許有空值，一般是在創(chuàng)建表的同時(shí)創(chuàng)建主鍵索引。

4.組合索引 ---- 在多個(gè)字段上創(chuàng)建的索引，只有在查詢(xún)條件中使用了創(chuàng)建索引時(shí)的第一個(gè)字段，索引才會(huì)被使用。

5.fulltext ---- 全文索引,是對(duì)于大表的文本域：char，varchar，text列才能創(chuàng)建全文索引，主要用于查找文本中的關(guān)鍵字，并不是直接與索引中的值進(jìn)行比較。fulltext更像是一個(gè)搜索引擎，配合match against操作使用，而不是一般的where語(yǔ)句加like。

注:全文索引目前只有MyISAM存儲(chǔ)引擎支持全文索引，InnoDB引擎5.6以下版本還不支持全文索引

所有存儲(chǔ)引擎對(duì)每個(gè)表至少支持16個(gè)索引，總索引長(zhǎng)度至少為256字節(jié)，索引有兩種存儲(chǔ)類(lèi)型，包括B型樹(shù)索引和哈希索引。

索引可以提高查詢(xún)的速度，但是創(chuàng)建和維護(hù)索引需要耗費(fèi)時(shí)間，同時(shí)也會(huì)影響插入的速度，如果需要插入大量的數(shù)據(jù)時(shí)，最好是先刪除索引，插入數(shù)據(jù)后再建立索引。

八.sql語(yǔ)句分類(lèi)：

DDL：數(shù)據(jù)定義語(yǔ)言（create drop）

DML：數(shù)據(jù)操作語(yǔ)句（insert update delete）

DQL：數(shù)據(jù)查詢(xún)語(yǔ)句（select ）

DCL：數(shù)據(jù)控制語(yǔ)句，進(jìn)行授權(quán)和權(quán)限回收（grant revoke）

TPL：數(shù)據(jù)事務(wù)語(yǔ)句（commit collback savapoint）