作者：navyaijm2017
一、環境說明
1、叢集部署以及配置
| IP | 配置 | 部署角色 | 部署版本 |
| 172.21.xx.43 | 8C16G 500G SSD | PD、Tidb | v3.0.12、v4.0.0-rc |
| 172.21.xx.44 | 4C8G 500G SSD | PD、Monitoring | v3.0.12、v4.0.0-rc |
| 172.21.xx.45 | 4C8G 500G SSD | PD | v3.0.12、v4.0.0-rc |
| 172.21.xx.46 | 8C16G 500G SSD | Tikv | v3.0.12、v4.0.0-rc |
| 172.21.xx.47 | 8C16G 500G SSD | Tikv | v3.0.12、v4.0.0-rc |
| 172.21.xx.48 | 8C16G 500G SSD | Tikv | v3.0.12、v4.0.0-rc |
| 172.21.xx.49 | 8C16G 500G SSD | Tiflash | v4.0.0-rc |
| 172.21.yy.4 | 16G32G 5T SSD | Mysql | 5.6.29 |
2、部署情況
a、在一套伺服器上同時部署v3和v4兩個版本的兩個叢集，但是不同時啟動，壓測哪個版本的時候啟動哪個叢集，保證兩個叢集不互相影響，同時也保證了底層的硬體資源環境相同
b、部署叢集用的參數都是預設參數，沒有做過特殊修改
二、測試
關于使用性能測試工具的測試結果，官方有相關資料，我這裡用我們具體的一個業務場景來測試，就是一個統計的SQL
1、測試結果
| 表資料量 | 查詢對象 | 查詢耗時 |
| 9860萬 | Mysql | 8分鐘4秒 |
| 9860萬 | Tidb V3 | 32秒 |
| 9860萬 | Tidb V4 for Tikv | 25秒 |
| 9860萬 | Tidb V4 for Tiflash | 7.5秒 |
2、測試說明
a、這是一個記錄對象存儲檔案記錄的表，表裡面的資料量大概是9860萬，下面是表結構
CREATE TABLE `ois_file_record` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '代理主鍵',
`file_name` varchar(128) NOT NULL DEFAULT '' COMMENT '檔案名稱（包含字尾名）',
`file_folder` varchar(64) NOT NULL DEFAULT '' COMMENT '檔案夾名稱（長度限制）',
`file_key` varchar(255) DEFAULT NULL COMMENT '',
`file_type` int(11) NOT NULL DEFAULT '6' COMMENT '',
`file_size` bigint(11) NOT NULL DEFAULT '0' COMMENT '',
`identify` varchar(32) NOT NULL DEFAULT '' COMMENT '',
`storage_type` int(11) NOT NULL COMMENT '',
`bucket_type` int(11) NOT NULL COMMENT '',
`bucket_name` varchar(32) NOT NULL DEFAULT '' COMMENT '',
`status` int(11) NOT NULL DEFAULT '1' COMMENT '',
`is_delete` int(11) NOT NULL DEFAULT '0' COMMENT '',
`create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '建立時間',
`update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時間',
PRIMARY KEY (`id`),
KEY `idx_file_key` (`file_key`) USING HASH COMMENT '',
KEY `idx_identify` (`identify`) USING HASH COMMENT ''
) ENGINE=InnoDB AUTO_INCREMENT=98603554 DEFAULT CHARSET=utf8 COMMENT='檔案記錄表' | b、下面這個SQL是業務方用到的一個統計SQL，我們就用這個SQL對比下MySQL、TiDB3、TiDB4的速度
SELECT SUM(file_size) as fileSize,COUNT(id) as fileCount,DATE_FORMAT(create_time,'%Y-%m-%d') as dateTime FROM ois_file_record WHERE identify = 'vehicle' and storage_type = 4 and bucket_type = 2 and is_delete = 0 and create_time > '2019-12-01 00:00:00' and file_key LIKE '%/video_data/%' GROUP BY DATE_FORMAT(create_time,'%Y-%m-%d') \"G
2、測試過程
a、下圖是MySQL上的結果，這個SQL跑出來需要8分鐘4秒
b、下圖是v4.0.0-rc版本，沒有開啟TiFlash副本的結果，這個SQL跑出來需要25秒\
\
c、下圖是v4.0.0-rc版本，開啟1個TiFlash副本的結果，這個SQL跑出來需要7.5秒\
d、下圖是v3.0.12的版本，這個SQL跑出來需要32秒\
三、總結
1、TiDB 4.0 對于AP場景，在不開啟TiFlash的情況下，相對于3.0的版本性能 提升不太明顯，但是開啟TiFlash副本的話，性能提升特别大，我上面的場景提升了4倍。
2、我們使用TiDB主要是兩個場景，一個是大資料量解決MySQL分庫分表的問題，不需要業務方寫業務邏輯，也不依賴中間件，平滑從MySQL遷移到TiDB；另一個場景是AP場景，我們把生産環境的多個庫通過DM彙聚到TiDB叢集做報表、統計相關業務。
3、TiDB 4.0，最吸引我的就是資料存儲同時支援行存（TiKV）+列存（TiFlash），并且可以獨立分開部署，互相不影響，使用者無需關系自己的查詢是AP還是TP，TiDB會自己判斷
4、4.0畢竟剛RC了幾天，還是有些小問題的，但是官方響應很積極，我覺得這也是為啥TiDB能發展這麼好很重要的原因吧，我測試過程中遇到幾個問題如下：
a、TiUP部署的時候，Y/N那塊如果輸入一個其他字元，程式就直接退出了，我覺得這塊應該優化下，判斷使用者輸入的不是Y或者N的話就一直讓使用者輸入，而不是直接退出