TiDB，有点意思了。
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考虑的还是很周全的。
更多更有意思的功能，后续看到了，我继续分享。