常見問題
分庫分表
對于海量數(shù)據(jù)，且有一定的并發(fā)量的分庫分表，絕不是引入某一個分庫分表中間件就能解決問題，而是一項系統(tǒng)的工程。需要分析整個表相關(guān)的業(yè)務(wù)，讓合適的中間件做它最擅長的事情。例如有sharding column的查詢走分庫分表，一些模糊查詢，或者多個不固定條件篩選則走es，海量存儲則交給HBase。
做了這么多事情后，后面還會有很多的工作要做，比如數(shù)據(jù)同步的一致性問題，還有運行一段時間后，某些表的數(shù)據(jù)量慢慢達到單表瓶頸，這時候還需要做冷數(shù)據(jù)遷移。
參考文檔
https://www.cnblogs.com/twoheads/p/10715498.html
緩存
mysql
官方資料
https://dev.mysql.com/doc/refman/8.0/en/
整體架構(gòu)
SQL層的功能
select * from wordpress.user;
DDL 數(shù)據(jù)庫定義語言
DCL 數(shù)據(jù)庫控制語言
DML 數(shù)據(jù)庫操作語言
DQL 數(shù)據(jù)查詢語言
1、判斷語法、語句、語義
判斷語句類型 2、數(shù)據(jù)庫不能直接響應(yīng)sql語句
必須明確的知道數(shù)據(jù)在哪個磁盤 3、數(shù)據(jù)庫對象授權(quán)情況判斷
授權(quán)失敗不繼續(xù)4、解析(解析器)
將sql語句解析成執(zhí)行計劃，運行執(zhí)行計劃，生成找數(shù)據(jù)的方式5、優(yōu)化 (優(yōu)化器)
運行執(zhí)行計劃
5.6之后 基于代價的算法，從執(zhí)行計劃中選擇代價最小的交給"執(zhí)行器"6、"執(zhí)行器" 運行執(zhí)行計劃
最終生產(chǎn)如何去磁盤找數(shù)據(jù)方式7、將取數(shù)據(jù)的方式，交由下層(存儲引擎層)進行處理8、最終將取出的數(shù)據(jù)抽象成管理員或用戶能看懂的方式(表)，展現(xiàn)在用戶面前9、查詢緩存： 緩存之前查詢的數(shù)據(jù)。
假如我們查詢的表是一個經(jīng)常有變動的表，查詢緩存不要設(shè)置太大
存儲引擎
存儲引擎用于：
存儲數(shù)據(jù)、檢索數(shù)據(jù)、通過索引查找數(shù)據(jù)
存儲介質(zhì)、 事務(wù)功能、 鎖定、備份和恢復(fù)、優(yōu)化
特殊功能：
全文搜索、引用完整性、空間數(shù)據(jù)處理
雙層處理
上層包括SQL解析器和優(yōu)化器、下層包含一組存儲引擎
SQL 層不依賴于存儲引擎：
引擎不影響SQL處理
版本信息
1. MySQL Community Server 社區(qū)版本，開源免費，但不提供官方技術(shù)支持。
2. MySQL Enterprise Edition 企業(yè)版本，需付費，可以試用30天。
3. MySQL Cluster 集群版，開源免費?？蓪讉€MySQL Server封裝成一個Server。
4. MySQL Cluster CGE 高級集群版，需付費。
5. MySQL Workbench（GUITOOL）一款專為MySQL設(shè)計的ER/數(shù)據(jù)庫建模工具。它是著名的數(shù)據(jù)庫設(shè)計工具DBDesigner4的繼任者。MySQLWorkbench又分為兩個版本，分別是社區(qū)版（MySQL Workbench OSS）、商用版（MySQL WorkbenchSE）。
版本特性
功能
MySQL數(shù)據(jù)庫從5.7.8版本開始，也提供了對JSON的支持。對比PG和mysql：
1. 在共有功能上，pg比mysql要快一些
2. pg比mysql多一些操作json的函數(shù)
3. pg自定義函數(shù)功能比較強，針對json操作可以較好地進行模塊化開發(fā)，不一定要全部揉在一個sql里
4. pg支持函數(shù)索引，這樣可以對json中的某個值建立索引而不用在表上加減字段
選擇：
如果對json有頻繁的操作，而且需要復(fù)雜的操作，現(xiàn)階段來說pg是你唯一的選擇
如果對json操作功能性要求比較少，并且對其操作的強度也不高，建議選擇最熟悉的數(shù)據(jù)庫
一切都是發(fā)展的，說不定未來mysql對json的支持會越來越好，所以如果沒必要，選擇自己/團隊最熟悉的數(shù)據(jù)庫
pg的json和jsonb
從PostgreSQL 9.3開始，json就成了postgres里的一種數(shù)據(jù)類型。jsonb格式是json的二進制形式，二者的區(qū)別在于json寫入快，讀取慢，jsonb寫入慢，讀取快，但在操作上，二者是沒有區(qū)別的
（1）json存儲快，使用慢； 存的時候不做處理，使用時再解析
（2）jsonb存儲稍慢，存儲時就做了解析，使用時速度較快
（3）兩者的部分函數(shù)很相似，稍有區(qū)別
generate column， generated column是MySQL 5.7引入的新特性，所謂generated column，就是數(shù)據(jù)庫中這一列由其他列計算而得。
性能
在MySQL 5.7中，性能相關(guān)的改進非常多，包括臨時表相關(guān)的性能改進、只讀事務(wù)的性能優(yōu)化、連接建立速度的優(yōu)化和復(fù)制性能的改進。
臨時表的性能改進
MySQL 5.7 為了提高臨時表相關(guān)的性能，對臨時表相關(guān)的部分進行了大幅修改，包括引入新的臨時表空間；對于臨時表的DDL，不持久化相關(guān)表定義；對于臨時表的DML，不寫redo，關(guān)閉change buffer等。所有臨時表的改動，都基于以下兩個事實 ：
1.臨時表只在當前會話中可見
2.臨時表的生命周期是當前連接（MySQL宕機或重啟，則當前連接結(jié)束）
也就是說，對于臨時表的操作，不需要其他數(shù)據(jù)一樣嚴格地進行一致性保證。通過不持久化元信息，避免寫redo等方式，減少臨時表操作的IO，以提高臨時表操作的性能。
可用性
在線設(shè)置 復(fù)制的過濾規(guī)則 不再需要重啟MySQL，只需要停止SQL thread，修改完成以后，啟動SQL thread
在線修改buffer pool的大小
Online DDL MySQL 5.7支持重命名索引和修改varchar的大小，這兩項操作在之前的版本中，都需要重建索引或表
ALTER TABLE t1 ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(255);
在線開啟GTID ，在之前的版本中，由于不支持在線開啟GTID，用戶如果希望將低版本的數(shù)據(jù)庫升級到支持GTID的數(shù)據(jù)庫版本，需要先關(guān)閉數(shù)據(jù)庫，再以GTID模式啟動，所以導(dǎo)致升級起來特別麻煩。MySQL 5.7以后，這個問題不復(fù)存在
高可用方案
點擊鏈接進入：高可用方案
mysql常見命令
索引
分布式事務(wù)
分布式數(shù)據(jù)庫中間件
參數(shù)理解
系統(tǒng)默認參數(shù)
數(shù)據(jù)庫版本：mysql Ver 14.14 Distrib 5.7.27-30, for Linux (x86_64) using 6.2
事務(wù)隔離級別
tx_isolation | REPEATABLE-READ
transaction_isolation | REPEATABLE-READ
線程池大小
| thread_pool_size | 2 |
| thread_pool_stall_limit | 500
| thread_pool_high_prio_tickets | 4294967295 |
| thread_pool_idle_timeout | 60 | thread_pool_max_threads | 100000
binlog三種復(fù)制方式
二進制binlog的格式有三種：
statement：基于sql的binlog，每條修改數(shù)據(jù)的sql都會保存到binlog里。
row：基于行級別，記錄每一行數(shù)據(jù)的變化，也就是將每一行數(shù)據(jù)的變化都記錄到binlog里，記錄非常詳細。
mixed：混合statement和row模式。
WAL
數(shù)據(jù)庫中間件
分類
主要是mysql proxy,Amoeba, mycat 和 shardding jdbc
Mysql proxy
MySQL讀寫分離是指讓master處理寫操作，讓slave處理讀操作，非常適用于讀操作量比較大的場景，可減輕master的壓力。
使用mysql-proxy實現(xiàn)mysql的讀寫分離，mysql-proxy實際上是作為后端mysql主從服務(wù)器的代理，它直接接受客戶端的請求，對SQL語句進行分析，判斷出是讀操作還是寫操作，然后分發(fā)至對應(yīng)的mysql服務(wù)器上。
mysql-proxy是官方提供的mysql中間件產(chǎn)品可以實現(xiàn)負載平衡，讀寫分離，failover等
MySQL Proxy就是這么一個中間層代理，簡單的說，MySQL Proxy就是一個連接池，負責將前臺應(yīng)用的連接請求轉(zhuǎn)發(fā)給后臺的數(shù)據(jù)庫，并且通過使用lua腳本，可以實現(xiàn)復(fù)雜的連接控制和過濾，
從而實現(xiàn)讀寫分離和負載平衡。對于應(yīng)用來說，MySQL Proxy是完全透明的，應(yīng)用則只需要連接到MySQL Proxy的監(jiān)聽端口即可。
當然，這樣proxy機器可能成為單點失效，但完全可以使用多個proxy機器做為冗余，在應(yīng)用服務(wù)器的連接池配置中配置到多 個proxy的連接參數(shù)即可。
Amoeba
下載地址： http://sourceforge.net/projects/amoeba/files/
Amoeba主要解決以下問題：
a). 數(shù)據(jù)切分后復(fù)雜數(shù)據(jù)源整合
b). 提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響
c). 降低數(shù)據(jù)庫與客戶端連接
d). 讀寫分離路由
不足
a)、目前還不支持事務(wù)
b)、暫時不支持存儲過程（近期會支持）
c)、不適合從amoeba導(dǎo)數(shù)據(jù)的場景或者對大數(shù)據(jù)量查詢的query并不合適（比如一次請求返回10w以上甚至更多數(shù)據(jù)的場合）
d)、暫時不支持分庫分表，amoeba目前只做到分數(shù)據(jù)庫實例，每個被切分的節(jié)點需要保持庫表結(jié)構(gòu)一致：
更多信息參考：http://www.itdecent.cn/p/4aec9f682509
shardding jdbc
http://www.itdecent.cn/writer#/notebooks/29164998/notes/54241036
Mycat
github地址：https://github.com/MyCATApache/Mycat-Server
依賴關(guān)系速閱覽：https://github.com/MyCATApache/Mycat-Server/blob/1.6/pom.xml
主要功能
一個徹底開源的，面向企業(yè)應(yīng)用開發(fā)的大數(shù)據(jù)庫集群
支持事務(wù)、ACID、可以替代MySQL的加強版數(shù)據(jù)庫
一個可以視為MySQL集群的企業(yè)級數(shù)據(jù)庫，用來替代昂貴的Oracle集群
一個融合內(nèi)存緩存技術(shù)、NoSQL技術(shù)、HDFS大數(shù)據(jù)的新型SQL Server
結(jié)合傳統(tǒng)數(shù)據(jù)庫和新型分布式數(shù)據(jù)倉庫的新一代企業(yè)級數(shù)據(jù)庫產(chǎn)品
一個新穎的數(shù)據(jù)庫中間件產(chǎn)品
原理
**MyCAT通過定義表的分片規(guī)則來實現(xiàn)分片，每個表格可以捆綁一個分片規(guī)則，每個分片規(guī)則指定一個分片字段并綁定一個函數(shù)，來實現(xiàn)動態(tài)分片算法 **
**1.Schema：邏輯庫，與MySQL中的Database（數(shù)據(jù)庫）對應(yīng)，一個邏輯庫中定義了所包括的Table。 **
**2.Table：邏輯表，即物理數(shù)據(jù)庫中存儲的某一張表，與傳統(tǒng)數(shù)據(jù)庫不同，這里的表格需要聲明其所存儲的邏輯數(shù)據(jù)節(jié)點DataNode。在此可以指定表的分片規(guī)則。 **
**3.DataNode：MyCAT的邏輯數(shù)據(jù)節(jié)點，是存放table的具體物理節(jié)點，也稱之為分片節(jié)點，通過DataSource來關(guān)聯(lián)到后端某個具體數(shù)據(jù)庫上 **
4.DataSource：定義某個物理庫的訪問地址，用于捆綁到Datanode上
5、分片規(guī)則：前面講了數(shù)據(jù)切分，一個大表被分成若干個分片表，就需要一定的規(guī)則，這樣按照某種業(yè)務(wù)規(guī)則把數(shù)據(jù)分到某個分片的規(guī)則就是分片規(guī)則，數(shù)據(jù)切分選擇合適的分片規(guī)則非常重要，將極大的避免后續(xù)數(shù)據(jù)處理的難
優(yōu)勢
基于阿里開源的Cobar產(chǎn)品而研發(fā)，Cobar的穩(wěn)定性、可靠性、優(yōu)秀的架構(gòu)和性能以及眾多成熟的使用案例使得MYCAT一開始就擁有一個很好的起點，站在巨人的肩膀上，我們能看到更遠。業(yè)界優(yōu)秀的開源項目和創(chuàng)新思路被廣泛融入到MYCAT的基因中，使得MYCAT在很多方面都領(lǐng)先于目前其他一些同類的開源項目，甚至超越某些商業(yè)產(chǎn)品。
完全實現(xiàn)分布式事務(wù)，完全的支持分布式。
通過Mycat web（eye）完成可視化配置，及智能監(jiān)控，自動運維。
通過mysql 本地節(jié)點，完整的解決數(shù)據(jù)擴容難度，實現(xiàn)自動擴容機制，解決擴容難點。
支持基于zookeeper的主從切換及Mycat集群化管理。
通過Mycat Balance 替代第三方的Haproxy，LVS等第三方高可用，完整的兼容Mycat集群節(jié)點的動態(tài)上下線。
接入Spark等第三方工具，解決數(shù)據(jù)分析及大數(shù)據(jù)聚合的業(yè)務(wù)場景。
通過Mycat智能優(yōu)化，分析分片熱點，提供合理的分片建議，索引建議，及數(shù)據(jù)切分實時業(yè)務(wù)建議
1.6版本架構(gòu)
基于spring鏈接主從模式的服務(wù)端
https://blog.csdn.net/kingmax54212008/article/details/83716753
索引
組合索引
遵循左相關(guān)原則，與最左邊關(guān)聯(lián)系最強為原則。
舉例如下：
CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL,
city VARCHAR(50) NOT NULL,
age INT NOT NULL
);
ALTER****TABLE mytable ADD****INDEX name_city_age (name(10),city,age);
如果分別在 usernname，city，age上建立單列索引，讓該表有3個單列索引，查詢時和上述的組合索引效率也會大不一樣，遠遠低于我們的組合索引。雖然此時有了三個索引，但MySQL只能用到其中的那個它認為似乎是最有效率的單列索引。
建立這樣的組合索引，其實是相當于分別建立了下面三組組合索引：
usernname,city,age
usernname,city
usernname
相關(guān)參考：
https://blog.csdn.net/weixin_42181824/article/details/82261988
https://baijiahao.baidu.com/s?id=1615219189673304134&wfr=spider&for=pc
secondary index
除了聚簇索引之外的其他索引類型都屬于二級索引。在Innodb中，二級索引的每行數(shù)據(jù)都包含這條數(shù)據(jù)的主鍵列，還有二級索引指定的列；聚簇索引中，innodb通過主鍵值來查找數(shù)據(jù)行。
mysql索引回表概念
（1）先通過普通索引(普通索引，唯一索引，組合索引)定位到主鍵值；
（2）在通過聚集索引定位到行記錄；
這就是所謂的回表查詢，先定位主鍵值，再定位行記錄，然后根據(jù)行記錄數(shù)主鍵id掃描索引數(shù)，查詢出數(shù)據(jù)，它的性能較掃一遍索引樹更低
舉例說明：當有一個表有四個字段，分別是id、name，age、address四個字段，將id設(shè)置為主鍵索引，將name和age設(shè)置為組合索引
查詢語句如下：
select name, age, address from table where name = xxx and age = xxx
得出結(jié)論如下：根據(jù)組合索引規(guī)范，最左原則和用法，其實組合索引用到了。但是address字段沒有建立索引，根據(jù)已經(jīng)通過索引查詢出的記錄的主鍵id，根據(jù)主鍵id在去遍歷索引樹獲取數(shù)據(jù)，這個過程就叫做回表。
如果查詢語句變化下：
select id, name, age from table where name = xxx and age = xxx
得出結(jié)論如下：因為id已經(jīng)有索引，所以不需要回表，那么這就是覆蓋索引。
索引優(yōu)化
全值匹配心上人（這是基本原則），最左前綴要遵行（聯(lián)合索引一般都圍繞最左前綴優(yōu)化）；
帶頭大哥活才行（聯(lián)合索引從最左邊字段開始使用），中間兄弟規(guī)矩行（不能跳過中間的字段，跳過后索引無效）；
索引列上少計算（索引列上盡量不要進行計算），范圍之后全完蛋（where后面使用范圍查詢的之后的索引無效）；
like百分最右寫（%號寫最右邊，寫左邊會導(dǎo)致索引失效），覆蓋索引別寫星（盡量避免select*這樣的語句，能寫索引列最好）；
空值不等還有or，索引失效最無情（is null，is not null，!=，<>，or會導(dǎo)致索引無效）；
https://blog.csdn.net/yhl_jxy/article/details/88636685
更全面的
http://www.itdecent.cn/p/21c9a9ee7a90
索引執(zhí)行
從源碼來看
https://blog.csdn.net/vipshop_fin_dev/article/details/79688717
分布式事務(wù)
協(xié)議
分布式基礎(chǔ)協(xié)議：CAP， BASE
分布式事務(wù)協(xié)議或框架：XA，TCC，saga，本地消息表+最終一致性
XA協(xié)議
XA是一個分布式事務(wù)協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器
分為兩個協(xié)議： 兩階段協(xié)議和三階段協(xié)議
三階段協(xié)議.
相比于兩階段的優(yōu)勢：
- 協(xié)調(diào)器和參與者加入了超時機制
2. 準備階段拆分為兩階段，防止參與者在準備后發(fā)生奔潰無法知曉是否提交或回滾的不確定狀態(tài)所引起的延時和數(shù)據(jù)不一致問題。
- 在precommit階段等待超時后會直接提交，解決了二階段單點故障后一直等待占用資源的問題。
遺留的問題：
當?shù)谌齻€階段準備發(fā)起abort時，事務(wù)協(xié)調(diào)器出現(xiàn)故障，會導(dǎo)致數(shù)據(jù)不一致
相關(guān)參考
https://www.cnblogs.com/cxxjohnson/p/9145548.html
存儲引擎
常見引擎:XtraDB MyISAM InnoDB NDB
XtraDB
優(yōu)點：
可擴展性：處理更多事務(wù)；在強大的服務(wù)器上進行擴展
性能：使用了XtraDB的Percona Server速度非?？欤聞?wù)處理能力是innodb的2.7倍。
可靠性：避免損壞，提供崩潰安全(crash-safe)復(fù)制
管理：在線備份，在線表格導(dǎo)入/導(dǎo)出
診斷：高級分析和檢測
靈活性：可變的頁面大小，改進的緩沖池管理
產(chǎn)品Percona 和MariaDB
percona開發(fā)了xtraDB存儲引擎。mariaDB使用了XtraDb，同時也提供myisam和innodb，是mysql的替代品，由mysql的創(chuàng)建者Monty Widenius成立一個家非盈利公司維護，公司由產(chǎn)品驅(qū)動，后續(xù)的發(fā)展具有不可確定性。
MariaDB
另一款提供了XtraDB存儲引擎的產(chǎn)品是MariaDB產(chǎn)品。它與Percona產(chǎn)品非常類似，但是提供了更多底層代碼更改，試圖提供比標準MySQL更多的性能改進。MariaDB直接利用來自Percona的XtraDB引擎，由于它們使用的是完全相同的引擎，因此每次使用存儲引擎時沒有顯著的差別。
產(chǎn)品Drizzle
mysql的一分支，對mysql做了重大修改
語言從c到c++的變更
完全開源
價格是mysql 的一半，目標云市場
瞄準高可用，修改一些已知的bug
