随着对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官方文档：
http://218.206.242.148:12345/images/20_tencent/20220917/lho1omhnjcd
其实这种小功能的开发成本本身也不会很大，但是有了这些功能，用户在数据库的时候，就不会是一个黑盒，更有操控感。不得不说，这些细节上，TiDB考虑的还是很周全的。
更多更有意思的功能，后续看到了，我继续分享。
