TiDB管理
一、系统表
mysql 库里存储的是 TiDB 系统表
1、权限系统表
user：用户账户，全局权限
user表的权限是全局的，并且不管默认数据库是哪一个。比如user里面有DELETE权限，任何一行，任何的表，任何的数据库。User+Host可能会匹配user表里面多行，为了处理这种情况，user表的行是排序过的，客户端连接时会依次去匹配，并使用首次匹配到的那一行做权限验证。排序是按Host在前，User在后。
db：数据库级别的权限
db表里面，User 为空是匹配匿名用户，User 里面不能有通配符。Host 和 Db 列里面可以有%和_，可以模式匹配。tables_priv：表级别的权限
tables_priv和columns_priv中使用%是类似的，但是在Db,Table_name,Column_name这些列不能包含%。加载进来时排序也是类似的。columns_priv：列级别的权限，当前暂不支持
权限生效时机
- TiDB 启动时，将一些权限检查的表加载到内存，之后使用缓存的数据来验证权限。系统会周期性的将授权表从数据库同步到缓存，生效则是由同步的周期决定，目前这个值设定的是 5 分钟。
- 如果授权表已被直接修改，则不会通知 TiDB 节点更新缓存，如果需要立即生效，可以手动执行
FLUSH PRIVILEGES;
2、服务端帮助信息系统表
help_topic目前为空
3、统计信息相关系统表
stats_buckets统计信息的桶stats_histograms统计信息的直方图stats_meta表的元信息，比如总行数和修改数analyze_jobs正在执行的统计信息收集任务以及过去 7 天内的历史任务记录
4、GC Worker 相关系统表
gc_delete_range
5、其它系统表
GLOBAL_VARIABLES全局系统变量表tidb用于 TiDB 在 bootstrap 的时候记录相关版本信息
二、用户管理
1、用户管理
-- 创建用户
CREATE USER `testuser`@`192.168.1.1` IDENTIFIED BY '密码';
-- 给用户授权
GRANT Select,UPDATE,INSERT,CREATE,DELETE ON `test`.* TO `testuser`@`192.168.1.1`;
-- 查看用户权限
show grants for 'test'@'192.168.1.1';
-- 回收用户权限
REVOKE ALL PRIVILEGES ON `test`.* FROM 'testuser'@'192.168.1.1';
-- 删除用户
DROP USER 'testuser'@'192.168.1.1';
2、创建Dashboard访问用户
Dashboard访问用户所需权限
当所连接的 TiDB 服务器未启用安全增强模式 (SEM) 时，要访问 TiDB Dashboard，SQL 用户应当拥有以下所有权限：
- PROCESS
- SHOW DATABASES
- CONFIG
- DASHBOARD_CLIENT
- 无IP限制，创建时使用%不限制用户登录IP
CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY '<YOUR_PASSWORD>'; GRANT PROCESS, CONFIG ON *.* TO 'dashboardAdmin'@'%'; GRANT SHOW DATABASES ON *.* TO 'dashboardAdmin'@'%'; GRANT DASHBOARD_CLIENT ON *.* TO 'dashboardAdmin'@'%';当所连接的 TiDB 服务器启用了安全增强模式 (SEM) 时，要访问 TiDB Dashboard，SQL 用户应当拥有以下所有权限：
- PROCESS
- SHOW DATABASES
- CONFIG
- DASHBOARD_CLIENT
- RESTRICTED_TABLES_ADMIN
- RESTRICTED_STATUS_ADMIN
- RESTRICTED_VARIABLES_ADMIN
- 无IP限制，创建时使用%不限制用户登录IP
CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY '<YOUR_PASSWORD>'; GRANT PROCESS, CONFIG ON *.* TO 'dashboardAdmin'@'%'; GRANT SHOW DATABASES ON *.* TO 'dashboardAdmin'@'%'; GRANT DASHBOARD_CLIENT ON *.* TO 'dashboardAdmin'@'%'; GRANT RESTRICTED_STATUS_ADMIN ON *.* TO 'dashboardAdmin'@'%'; GRANT RESTRICTED_TABLES_ADMIN ON *.* TO 'dashboardAdmin'@'%'; GRANT RESTRICTED_VARIABLES_ADMIN ON *.* TO 'dashboardAdmin'@'%';若希望 SQL 用户在登录 TiDB Dashboard 后允许修改界面上的各项配置，SQL 用户还应当拥有以下权限：
- SYSTEM_VARIABLES_ADMIN
-- 如果要使自定义的 SQL 用户能修改 TiDB Dashboard 界面上的各项配置，可以增加以下权限 GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'dashboardAdmin'@'%';
三、慢SQL
TiDB 会将执行时间超过 slow-threshold（默认值为 300 毫秒）的语句输出到 slow-query-file（默认值："tidb-slow.log"）日志文件中，用于帮助用户定位慢查询语句，分析和解决 SQL 执行的性能问题。
TiDB 默认启用慢查询日志，可以修改配置 enable-slow-log 来启用或禁用它。
Slow Query 基础信息
Time：表示日志打印时间。Query_time：表示执行这个语句花费的时间。Parse_time：表示这个语句在语法解析阶段花费的时间。Compile_time：表示这个语句在查询优化阶段花费的时间。Query：表示 SQL 语句。慢日志里面不会打印Query，但映射到内存表后，对应的字段叫Query。Digest：表示 SQL 语句的指纹。Txn_start_ts：表示事务的开始时间戳，也是事务的唯一 ID，可以用这个值在 TiDB 日志中查找事务相关的其他日志。Is_internal：表示是否为 TiDB 内部的 SQL 语句。true表示 TiDB 系统内部执行的 SQL 语句，false表示用户执行的 SQL 语句。Index_ids：表示语句涉及到的索引的 ID。Succ：表示语句是否执行成功。Backoff_time：表示语句遇到需要重试的错误时在重试前等待的时间，常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、tikv server is busy。Plan：表示语句的执行计划，用select tidb_decode_plan('xxx...')SQL 语句可以解析出具体的执行计划。Prepared：表示这个语句是否是Prepare或Execute的请求。Plan_from_cache：表示这个语句是否命中了执行计划缓存。Rewrite_time：表示这个语句在查询改写阶段花费的时间。Preproc_subqueries：表示这个语句中被提前执行的子查询个数，如where id in (select if from t)这个子查询就可能被提前执行。Preproc_subqueries_time：表示这个语句中被提前执行的子查询耗时。Exec_retry_count：表示这个语句执行的重试次数。一般出现在悲观事务中，上锁失败时重试执行该语句。Exec_retry_time：表示这个语句的重试执行时间。例如某个查询一共执行了三次（前两次失败），则Exec_retry_time表示前两次的执行时间之和，Query_time减去Exec_retry_time则为最后一次执行时间。
和事务执行相关的字段
Prewrite_time：表示事务两阶段提交中第一阶段（prewrite 阶段）的耗时。Commit_time：表示事务两阶段提交中第二阶段（commit 阶段）的耗时。Get_commit_ts_time：表示事务两阶段提交中第二阶段（commit 阶段）获取 commit 时间戳的耗时。Local_latch_wait_time：表示事务两阶段提交中第二阶段（commit 阶段）发起前在 TiDB 侧等锁的耗时。Write_keys：表示该事务向 TiKV 的 Write CF 写入 Key 的数量。Write_size：表示事务提交时写 key 或 value 的总大小。Prewrite_region：表示事务两阶段提交中第一阶段（prewrite 阶段）涉及的 TiKV Region 数量。每个 Region 会触发一次远程过程调用。
和内存使用相关的字段
Mem_max：表示执行期间 TiDB 使用的最大内存空间，单位为 byte。
和硬盘使用相关的字段
Disk_max: 表示执行期间 TiDB 使用的最大硬盘空间，单位为 byte。
和 SQL 执行的用户相关的字段
User：表示执行语句的用户名。Conn_ID：表示用户的链接 ID，可以用类似con:3的关键字在 TiDB 日志中查找该链接相关的其他日志。DB：表示执行语句时使用的 database。
和 TiKV Coprocessor Task 相关的字段
Request_count：表示这个语句发送的 Coprocessor 请求的数量。Total_keys：表示 Coprocessor 扫过的 key 的数量。Process_time：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过Query_time。Wait_time：表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队；当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加。Process_keys：表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多。Cop_proc_avg：cop-task 的平均执行时间。Cop_proc_p90：cop-task 的 P90 分位执行时间。Cop_proc_max：cop-task 的最大执行时间。Cop_proc_addr：执行时间最长的 cop-task 所在地址。Cop_wait_avg：cop-task 的平均等待时间。Cop_wait_p90：cop-task 的 P90 分位等待时间。Cop_wait_max：cop-task 的最大等待时间。Cop_wait_addr：等待时间最长的 cop-task 所在地址。Cop_backoff_{backoff-type}_total_times：因某种错误造成的 backoff 总次数。Cop_backoff_{backoff-type}_total_time：因某种错误造成的 backoff 总时间。Cop_backoff_{backoff-type}_max_time：因某种错误造成的最大 backoff 时间。Cop_backoff_{backoff-type}_max_addr：因某种错误造成的最大 backoff 时间的 cop-task 地址。Cop_backoff_{backoff-type}_avg_time：因某种错误造成的平均 backoff 时间。Cop_backoff_{backoff-type}_p90_time：因某种错误造成的 P90 分位 backoff 时间。
相关系统变量
- tidb_slow_log_threshold：设置慢日志的阈值，执行时间超过阈值的 SQL 语句将被记录到慢日志中。默认值是 300 ms。
- tidb_query_log_max_len：设置慢日志记录 SQL 语句的最大长度。默认值是 4096 byte。
- tidb_redact_log：设置慢日志记录 SQL 时是否将用户数据脱敏用
?代替。默认值是 0 ，即关闭该功能。 - tidb_enable_collect_execution_info：设置是否记录执行计划中各个算子的物理执行信息，默认值是
1。该功能对性能的影响约为 3%。
统计慢SQL
SELECT
DB AS '数据库',
`Query` AS 'SQL语句',
Query_time AS '执行耗时Query_time',
Time AS '执行时间',
`User` AS '执行用户',
`Host` AS '主机',
Total_keys AS '扫描总Key个数Total_keys',
Index_names AS '涉及索引名'
FROM
INFORMATION_SCHEMA.SLOW_QUERY
WHERE
DB = '数据库名'
ORDER BY
Query_time DESC
LIMIT 100;
四、TIDB集群安全相关
1、日志脱敏
①TiDB 组件日志脱敏
②TiKV 组件日志脱敏
③PD 组件日志脱敏
④TiFlash 组件日志脱敏
https://docs.pingcap.com/zh/tidb/stable/log-redaction
2、关闭发送遥测数据
①TiDB禁用遥测
动态禁用
# 修改系统全局变量tidb_enable_telemetry动态禁用 TiDB 遥测功能： SET GLOBAL tidb_enable_telemetry = 0;配置文件的禁用优先级高于全局变量。若通过配置文件禁用了遥测功能，则全局变量的配置将不起作用，遥测功能总是处于关闭状态。
集群级别禁用
修改集群配置文件
server_configs: tidb: enable-telemetry: false重启集群TiDB组件
②TiDB Dashboard禁用遥测
修改集群配置文件
server_configs:
pd:
dashboard.enable-telemetry: false
重启集群PD组件
③TiUP禁用遥测
tiup telemetry disable
# 禁用之后~/.tiup/telemetry/meta.yaml文件中的status字段会显示Disable
④TiSpark禁用遥测
在 Spark 配置文件设置 spark.tispark.telemetry.enable = false 来禁用 TiSpark 的遥测功能。
https://docs.pingcap.com/zh/tidb/stable/telemetry
五、下载的性能测试数据展示
在TIDB Dashboard中做的性能测试，数组只保存几天。可下载下来进行长期保存。如果要再次以Web形式展示，使用以下命令
go tool pprof --http=0.0.0.0:1234 cpu_xxx.proto
六、Kill进程
语法：KILL TIDB? ( 'CONNECTION' | 'QUERY' )? CONNECTION_ID
SELECT ID, USER, INSTANCE, MEM, TIME, INFO FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST order by TIME desc;
+---------------------+------+-----------------+-----------------------------------------------------------------------------+
| ID | USER | INSTANCE | INFO |
+---------------------+------+-----------------+-----------------------------------------------------------------------------+
| 8306449708033769879 | root | 127.0.0.1:10082 | select sleep(30), 'foo' |
| 5857102839209263511 | root | 127.0.0.1:10080 | select sleep(50) |
| 5857102839209263513 | root | 127.0.0.1:10080 | SELECT ID, USER, INSTANCE, INFO FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST |
+---------------------+------+-----------------+-----------------------------------------------------------------------------+
KILL 5857102839209263513;
MySQL 兼容性
- MySQL 的
KILL语句仅能终止当前连接的 MySQL 实例上的连接，TiDB 的KILL语句能终止整个集群中任意一个 TiDB 实例上的连接。 - 暂时不支持使用 MySQL 命令行 ctrl+c 终止查询或连接。
行为变更说明
TiDB 从 v6.1.0 起新增 Global Kill 功能（由 enable-global-kill 配置项控制，默认启用）。启用 Global Kill 功能时，KILL 语句和 KILL TIDB 语句均能跨节点终止查询或连接，且无需担心错误地终止其他查询或连接。当你使用客户端连接到任何一个 TiDB 节点执行 KILL 语句或 KILL TIDB 语句时，该语句会被转发给对应的 TiDB 节点。当客户端和 TiDB 中间有代理时，KILL 及 KILL TIDB 语句也会被转发给对应的 TiDB 节点执行。
对于 TiDB v6.1.0 之前的版本，或未启用 Global Kill 功能时：
KILL语句与 MySQL 不兼容，负载均衡器后面通常放有多个 TiDB 服务器，这种不兼容有助于防止在错误的 TiDB 服务器上终止连接。你需要显式地增加TIDB后缀，通过执行KILL TIDB语句来终止当前连接的 TiDB 实例上的其他连接。- 强烈不建议在配置文件里设置
compatible-kill-query = true，除非你确定客户端将始终连接到同一个 TiDB 节点。这是因为当你在默认的 MySQL 客户端按下 ctrl+c 时，客户端会开启一个新连接，并在这个新连接中执行KILL语句。此时，如果客户端和 TiDB 中间有代理，新连接可能会被路由到其他的 TiDB 节点，从而错误地终止其他会话。 KILL TIDB语句是 TiDB 的扩展语法，其功能与 MySQL 命令KILL [CONNECTION|QUERY]和 MySQL 命令行 ctrl+c 相同。在同一个 TiDB 节点上，你可以安全地使用KILL TIDB语句。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-kill#kill
七、忘记 root 密码
修改 TiDB 配置文件：
登录其中一台 tidb-server 实例所在的机器。
进入 TiDB 节点的部署目录下的
conf目录，找到tidb.toml配置文件。在配置文件的security部分添加配置项skip-grant-table。如无security部分，则将以下两行内容添加至 tidb.toml 配置文件尾部：
[security] skip-grant-table = true终止该 tidb-server 的进程：
- 找到 tidb-server 对应的进程 ID (PID) 并使用
kill命令停掉该进程：
ps aux | grep tidb-server kill -9 <pid>- 找到 tidb-server 对应的进程 ID (PID) 并使用
使用修改之后的配置启动 TiDB：
注意：设置
skip-grant-table之后，启动 TiDB 进程会增加操作系统用户检查，只有操作系统的root用户才能启动 TiDB 进程。进入 TiDB 节点部署目录下的
scripts目录。切换到操作系统
root账号。在前台执行目录中的
run_tidb.sh脚本。在新的终端窗口中使用
root登录后修改密码：mysql -h 127.0.0.1 -P 4000 -u root- 停止运行
run_tidb.sh脚本，并去掉第 1 步中在 TiDB 配置文件中添加的内容，等待 tidb-server 自启动。
- 停止运行