TiDB，有點意思了。
随着對TiDB的接觸越來越多，發現這個分布式資料庫在某些功能上确實設計的更加人性化，今天線上上的TiDB的運維過程中，又發現了TiDB的一個優點，這裡必須表揚一下。
從官方角度看，TiDB的幾大優點如下：
- 一鍵水準擴容或者縮容
- 金融級高可用
- 實時 HTAP
- 雲原生的分布式資料庫
- 相容 MySQL 5.7 協定和 MySQL 生态
不過我個人喜歡從一些使用者的角度去看待這個資料庫，說說TiDB這個小優點吧：
我們知道，在MySQL中，如果我們執行一個大表變更，alter table , 具體執行到什麼階段了，其實我們是無法知道的，隻有等待MySQL給我們傳回Query OK，我們才知道這個操作執行完了。
當然，如果你想知道alter table的執行進度，可以使用pt-osc工具，你能看到下面的輸出：
Copying `db`.`table`: 14% 02:52 remain
Copying `db`.`table`: 27% 02:38 remain
Copying `db`.`table`: 38% 02:22 remain
Copying `db`.`table`: 49% 02:00 remain
Copying `db`.`table`: 60% 01:37 remain
Copying `db`.`table`: 71% 01:11 remain
Copying `db`.`table`: 81% 00:46 remain
Copying `db`.`table`: 91% 00:21 remain
複制
從這個輸出結果，我們可以判斷目前正在進行的alter table操作的進度，同時還給出了一個剩餘的執行時間，這對于使用者來說，也是非常友好的。但是，pt-osc這個工具也是有一些限制的，假如表必須有主鍵等。
然而，在TiDB中，如果你執行一個alter table的語句，在用戶端沒有傳回的時候，可以通過另外一個用戶端利用
admin show ddl指令，檢視目前操作的進度，這個指令不會阻塞，如下：
admin show ddl;
*************************** 1. row ***************************
SCHEMA_VER: 140
OWNER: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc
RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganization,
SchemaID:1, TableID:118, RowCount:77312, ArgLen:0,
start time: 2021-12-05 16:26:10.652 +0800 CST, Err:<nil>, ErrCount:0, SnapshotVersion:404749908941733890
SELF_ID: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc
複制
上面操作結果可知，目前正在處理的是 add index 操作。且從 RowCount 字段可以知道目前 add index 操作已經添加了 77312 行記錄。而總的行數，其實可以通過select count(*) from table來擷取，這樣，我們一個SQL執行之後，就可以比較友善的擷取目前執行的進度了。對于執行時間，也可以有一個更加合理的估算值。
如果你想要一個更加詳細的結果，還可以通過
ADMIN SHOW DDL JOBS
語句用于檢視目前 DDL 作業隊列中的所有結果（包括正在運作以及等待運作的任務）以及已執行完成的 DDL 作業隊列中的最近十條結果。如下：
ADMIN SHOW DDL JOBS;
+--------+---------+--------------------+--------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE |
+--------+---------+--------------------+--------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------+
| 59 | test | t1 | add index | write reorganization | 1 | 55 | 88576 | 2020-08-17 07:51:58 | NULL | running |
| 60 | test | t2 | add index | none | 1 | 57 | 0 | 2020-08-17 07:51:59 | NULL | none |
| 58 | test | t2 | create table | public | 1 | 57 | 0 | 2020-08-17 07:41:28 | 2020-08-17 07:41:28 | synced |
| 56 | test | t1 | create table | public | 1 | 55 | 0 | 2020-08-17 07:41:02 | 2020-08-17 07:41:02 | synced |
| 54 | test | t1 | drop table | none | 1 | 50 | 0 | 2020-08-17 07:41:02 | 2020-08-17 07:41:02 | synced |
| 53 | test | t1 | drop index | none | 1 | 50 | 0 | 2020-08-17 07:35:44 | 2020-08-17 07:35:44 | synced |
| 52 | test | t1 | add index | public | 1 | 50 | 451010 | 2020-08-17 07:34:43 | 2020-08-17 07:35:16 | synced |
| 51 | test | t1 | create table | public | 1 | 50 | 0 | 2020-08-17 07:34:02 | 2020-08-17 07:34:02 | synced |
| 49 | test | t1 | drop table | none | 1 | 47 | 0 | 2020-08-17 07:34:02 | 2020-08-17 07:34:02 | synced |
| 48 | test | t1 | create table | public | 1 | 47 | 0 | 2020-08-17 07:33:37 | 2020-08-17 07:33:37 | synced |
| 46 | mysql | stats_extended | create table | public | 3 | 45 | 0 | 2020-08-17 06:42:38 | 2020-08-17 06:42:38 | synced |
| 44 | mysql | opt_rule_blacklist | create table | public | 3 | 43 | 0 | 2020-08-17 06:42:38 | 2020-08-17 06:42:38 | synced |
+--------+---------+--------------------+--------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------+
12 rows in set (0.00 sec)
複制
關于上面這個結果，更詳細的解釋可以參考TiDB官方文檔：
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-show-ddl/#admin-show-ddl-jobs
其實這種小功能的開發成本本身也不會很大，但是有了這些功能，使用者在資料庫的時候，就不會是一個黑盒，更有操控感。不得不說，這些細節上，TiDB考慮的還是很周全的。
更多更有意思的功能，後續看到了，我繼續分享。