> 本質上,TiDB是一個分布式的MySQL。
> 所以,先總結一下MySQL基本理解。
[TOC]
# 索引
## 索引優化
[如何對MySQL索引進行優化分析](https://zhuanlan.zhihu.com/p/71719831)
## 索引數據結構
[干貨:mysql索引的數據結構](https://www.jianshu.com/p/1775b4ff123a)
**MyISAM/InnoDB存儲引擎都用B+樹,但是存儲結構不同:**
* MyISAM數據文件和索引文件分離,葉子結點的Key是數據的地址,所以到了葉子,要根據地址查數據;
* InnoDB,主鍵的索引文件,葉子結點存儲的就是數據;非主鍵索引,葉子結點存儲的是主鍵的Key,所以對于InnoDB,主鍵索引特別快,因為只要B+樹查一遍,而非主鍵索引慢一點,因為到葉子后,還要再查一遍主鍵索引。
**通過這個結構的不同,我們也可以理解:**
* 為什么InnoDB必須主鍵而MyISAM不強制主鍵。
* 為什么InnoDB不建議使用過長的主鍵,因為會使輔助索引變得過大。
* 為什么InnoDB不建議非單調的字段做主鍵,因為插入時維持B+數需要頻繁分裂,而自增就比較好一點。
**B樹和B+樹最大的區別:**
B+樹葉子結點才有RowID(指向數據的指針),這樣在同樣數據的情況下,可以有更少的層級,減少磁盤IO。
## 索引建立耗時經驗數據
機器配置:28G內存,SSD硬盤;
數據10G,索引12G,總計耗時:58分鐘。
# MyISAM和InnoDB的區別
[Mysql 中 MyISAM 和 InnoDB 的區別有哪些?](https://www.zhihu.com/question/20596402)
**區別:**
InnoDB支持事務。
InnoDB支持外鍵。
InnoDB是聚集索引,MyISAM是非聚集索引。
MyISAM保存表的具體行數。
InnoDB鎖的最小力度是行鎖,MyISAM是表鎖,并發訪問受限。這也是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一。
**如何選擇:**
需要事務,只能用InnoDB。
絕大多數都是讀,可以考慮MyISAM;讀寫都頻繁,請用InnoDB。
系統奔潰后,MyISAM恢復起來更困難。
5.5之后,InnoDB是默認的,如果不知道如何選擇,請用InnoDB。
# 表空洞
Delete操作并不會減小數據表的占用空間:
[Mysql 表空間和 數據頁空洞](https://blog.csdn.net/qq_28018283/article/details/85003657)
[頁面存儲不聯系對性能的影響](https://segmentfault.com/q/1010000020223717)
這是因為不會物理刪除磁盤空間,除非整頁刪除(Page是Innodb存儲的最基本結構,也是Innodb磁盤管理的最小單位)。

**如何刪除表空洞:**
alter table xxx engine='InnoDB'
db平臺會建立新表,數據拷貝完畢,進行表名,所以這個操作耗時是和剩余數據量相關的。
[詳談 MySQL Online DDL](https://www.cnblogs.com/mysql-dba/p/6192897.html)
**刪除表空洞經驗執行時長:**
機器配置:28G內存,SSD硬盤;
剩余10G數據,6G索引,耗時38分鐘。
# Binlog
[Mysql數據庫之Binlog日志使用總結(必看篇)](https://blog.51cto.com/xiaocao13140/2126128)
purge master logs before '2019-10-29 00:00:00'
清除150G日志,任務耗時5秒。因為就是刪文件。DB平臺一般是1G一個Binlog文件,而DBA會限制最多50個Binlog,避免打爆磁盤。
# 性能瓶頸數據參考
**2017.11.23壓測:**
多功能一起壓測,很快DB出各種異常,各種數據庫問題,響應時間高;
單接口壓測,壓測其中一個慢的接口,getOrderDetail,QPS1000,數據庫讀QPS 6700,響應50毫秒;
單接口壓測,找出最慢的接口,getIncomeSummary,是5萬數據中的3萬數據Sum,這個接口是當日可用金額,QPS20,就會到2秒,最大11秒,持續壓,會拖垮數據庫;
**2017年來自DBA的經驗數據:**
你們多少臺業務機器,連接池這個要看你們業務機器數,這個數據庫的最大連接數是2K,只要不超過這個限制就好。
查詢QPS看單條SQL的掃描記錄,如果每條SQL查詢的記錄數在幾條到幾十條,按線上物理機的那種配置,可以到16-20K,線上一般考慮2倍容量,查詢可以到8-9K。
寫入QPS的話,看是否需要考慮從庫延遲,如果需要考慮從庫延遲的話,現在這個數據庫5.6,從庫同步的經驗值大概是3K左右,不過這個也要看具體的寫入SQL,如果每條寫SQL涉及的記錄數和記錄都比較簡單的話,線上有高的同步效率能夠到6-7K。
所以考慮2倍容量,經驗值的寫入QPS在1-1.5K。
# 分庫分表匯總
[數據庫分庫分表解決方案匯總](https://mp.weixin.qq.com/s/kESm-PLwaTbFgg5gPbX-0A)
# 樂觀鎖和悲觀鎖
樂觀鎖適用在“適度爭用”的情況下提高性能,因為沒有鎖的等待,馬上成功,或者失敗返回,或者失敗重試;在“激烈爭用”的場景下,只能用悲觀鎖。
對于一行記錄的更新,MySQL是悲觀鎖,TiDB(3.0.5)是樂觀鎖。
# 隔離級別
MySQL和Blade都是RR,不可重復讀。