> 本質上，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，不可重復讀。