如何确认一行数据的 mvcc 记录

API 使用：curl http://{TiDBIP}:10080/mvcc/key/{db}/{table}/{handle}

其中，handle id 是行号，如果是 clustered 表，那么就是主键，如果不是那么需要查 _tidb_rowid 隐藏列确认。

例如：

(root@127.0.0.1) [test]>select * from t;
+----+-------+
| id | value |
+----+-------+
|  1 |   100 |
|  2 |   200 |
+----+-------+
2 rows in set (0.01 sec)

(root@127.0.0.1) [test]>show create table t;
+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                                                                               |
+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| t     | CREATE TABLE `t` (
  `id` int NOT NULL,
  `value` int DEFAULT NULL,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  UNIQUE KEY `uq_value` (`value`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin |
+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

查看 mvcc 信息(注意我这里的 tidb-server 的 status port 调整为了 10180)：

curl -sl 127.0.0.1:10180/mvcc/key/test/t/1
{
 "key": "7480000000000000875F728000000000000001",
 "region_id": 3003,
 "value": {
  "info": {
   "writes": [
    {
     "start_ts": 458949167647817745,
     "commit_ts": 458949167660924930,
     "short_value": "gAABAAAAAgEAZA=="
    }
   ]
  }
 }
}

可以看到数据写入时间、数据 region 信息、key 信息等。

如何解析 key

有时候在日志或者一些报错信息中，可以看到一串 key 相关信息，如果想知道这个 key 代表什么，那么 tidb 有特定语法解析。比如上个章节中的 key，我们解析结果是：

select tidb_decode_key("7480000000000000875F728000000000000001");
+-----------------------------------------------------------+
| tidb_decode_key("7480000000000000875F728000000000000001") |
+-----------------------------------------------------------+
| {"id":1,"table_id":"135"}                                 |
+-----------------------------------------------------------+
1 row in set (0.01 sec)

这个就代表这个 key，是 table id 为 135 的表的，id 列为 1 的那行数据。

如何解析 short values

使用 tidb-ctl 查看：tidb-ctl base64decode [db_name.table_name] [base64_data]

还是按照当前案例来说：

tiup ctl:v8.5.2 tidb base64decode test.t gAABAAAAAgEAZA== --port 10180
Starting component ctl: /root/.tiup/components/ctl/v8.5.2/ctl tidb base64decode test.t gAABAAAAAgEAZA== --port 10180
id not found in data
value:        100

可以解析出这行数据内容

如何手动打散 table region 分布

开启方法：curl http://{TiDBIP}:10080/tables/{db}/{table}/scatter

关闭方法：curl http://{TiDBIP}:10080/tables/{db}/{table}/stop-scatter

查看一个 table 的 leader 和 region 的分布情况：

SELECT 
    b.DB_NAME AS 'db name',
    b.TABLE_NAME AS 'table name',
    d.ADDRESS AS 'tikv ip',
    COUNT(DISTINCT b.REGION_ID) AS 'region count',
    COUNT(DISTINCT CASE WHEN c.IS_LEADER = 1 THEN b.REGION_ID END) AS 'leader count'
FROM 
    information_schema.TIKV_REGION_STATUS b
    INNER JOIN information_schema.TIKV_REGION_PEERS c ON b.REGION_ID = c.REGION_ID
    INNER JOIN information_schema.TIKV_STORE_STATUS d ON c.STORE_ID = d.STORE_ID
WHERE 
    b.DB_NAME = 'test'
    AND b.TABLE_NAME = 't'
GROUP BY 
    b.DB_NAME,
    b.TABLE_NAME,
    d.ADDRESS
ORDER BY 
    b.DB_NAME,
    b.TABLE_NAME,
    d.ADDRESS;

这个主要在一些集中导入表数据，一般数据会比较集中，如果有大量扫数据行为，可能会导致热点问题。

如何确认哪个 tidb-server 是 ddl owner 节点

可以使用 admin show ddl; 命令查看

admin show ddl;
+------------+--------------------------------------+------------------+--------------+--------------------------------------+-------+
| SCHEMA_VER | OWNER_ID                             | OWNER_ADDRESS    | RUNNING_JOBS | SELF_ID                              | QUERY |
+------------+--------------------------------------+------------------+--------------+--------------------------------------+-------+
|       1068 | a8273aa4-616c-47fe-a0be-5398eb47e1eb | 10.2.103.80:4100 |              | a8273aa4-616c-47fe-a0be-5398eb47e1eb |       |
+------------+--------------------------------------+------------------+--------------+--------------------------------------+-------+
1 row in set (0.02 sec)

如何触发一次 tidb-server ddl owner 的切换

可以使用 resign 命令，例如：

curl -X POST http://127.0.0.1:10180/ddl/owner/resign
"success!"

如何解析 tso 时间

可以使用 pd-ctl tso 命令，例如（注意这里的 pd 端口有修改为 2399）：

tiup ctl:v8.5.2 pd -u 127.0.0.1:2399 -i
Starting component ctl: /root/.tiup/components/ctl/v8.5.2/ctl pd -u 127.0.0.1:2399 -i
» tso 458949167647817745;
system:  2025-06-24 16:02:14.887 +0800 CST
logic:   17

也可以用 tidb_parse_tso 函数，例如：

select tidb_parse_tso("458949167647817745");
+--------------------------------------+
| tidb_parse_tso("458949167647817745") |
+--------------------------------------+
| 2025-06-24 16:02:14.887000           |
+--------------------------------------+
1 row in set (0.00 sec)

如何确认一个表 mvcc 是否很多

执行 explain analyze select * from table，查看最终执行计划 total process keys 以及 keys skip 个数(key_skipped_count delete_skipped_count total_keys)。来判断 mvcc 是否很多。

注意： tikv 的开销大一些，可以考虑调低 tidb_distsql_scan_concurrency 扫描并发度。

TiDB 查问题常用技巧/命令