尧图网站建设 
TDengine 内建性能库 PERFORMANCE_SCHEMA 全解PERF_* 视图字段、权限与运行时观测实战【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengineTDengine 从v3.0.0.0起内置了只读数据库PERFORMANCE_SCHEMA以标准 SQL 视图形式对外暴露集群运行时的性能与状态数据客户端应用、连接、订阅消费者、执行中查询、实例注册与元数据事务。本文将逐表解析PERF_*的全部字段含义与数据类型结合仓库源码说明慢查询统计、心跳上报、权限分类等底层实现并给出可直接落地的排查实战 SQL帮助你在不侵入业务的前提下完成运行时观测与问题定位。一、PERFORMANCE_SCHEMA 是什么PERFORMANCE_SCHEMA是 TDengine 自带的系统数据库专门用于存放与性能相关的统计视图。它与另一套系统库INFORMATION_SCHEMA见 元数据信息INFORMATION_SCHEMA互为补充前者侧重运行时动态状态谁在连接、谁在查询、事务进行到哪一步后者侧重元数据与静态配置库表结构、配置项、用户权限等。同时这些视图中的大部分信息也都可以通过对应的 SHOW 命令 获取。从源码结构看PERFORMANCE_SCHEMA属于典型的“视图而非基表”设计它没有独立的数据文件数据由 mnode管理节点在内存中实时汇总仅支持查询、不支持INSERT等写入操作。其元数据由管理节点初始化时统一注册数据库名与表名常量定义在 include/common/systable.h其中TSDB_PERFORMANCE_SCHEMA_DB即performance_schema各表的列结构SSysDbTableSchema数组定义在 source/common/src/systable.c 的perfsMeta注册表中管理节点在启动时通过mndPerfsInitMeta把这些表结构装载进内存哈希并支持按表名动态返回表结构见 source/dnode/mnode/impl/src/mndPerfSchema.c。你甚至可以直接USE performance_schema把它设为默认库mnode 在 source/dnode/mnode/impl/src/mndDb.c 中对USE performance_schema做了专门处理之后用熟悉的SELECT语法查询并可使用过滤、排序、聚合等全部 TDengine SQL 能力。权限与可见性每个系统表在注册时都带有一个权限分类。当前 6 张PERF_*表中除PERF_INSTANCES属于PRIV_CAT_PRIVILEGED特权类外其余均属于PRIV_CAT_BASIC基础类见 include/common/systable.h 与 source/common/src/systable.c。这意味着普通用户默认可以查询大部分性能视图但部分节点级、实例级信息如PERF_INSTANCES会受到更严格的权限约束。当前已注册的表虽然头文件中定义了perf_smas、perf_offsets、perf_write_metrics等更多表名常量但从 source/common/src/systable.c 的注册表看当前实际生效的共有 6 张表表名主题PERF_APPS连接集群的客户端应用统计PERF_CONNECTIONS当前数据库连接PERF_CONSUMERS数据订阅消费者PERF_INSTANCES接入集群的实例注册信息PERF_QUERIES正在执行的查询PERF_TRANS正在执行的元数据事务二、PERF_APPS客户端应用的写入与查询统计PERF_APPS针对连接到集群的每个应用客户端提供写入/查询统计、慢查询计数和最近访问时间。它可以回答“哪个客户端在狂写”“哪个客户端的查询最慢、结果集最大”这类问题也可以直接用SHOW APPS查看同一份数据。#列名数据类型说明1app_idUBIGINT客户端 ID2ipVARCHAR(16)客户端地址3pidINT客户端进程 ID4nameVARCHAR(24)客户端名称5start_timeTIMESTAMP客户端启动时间6insert_reqUBIGINTINSERT请求次数7insert_rowUBIGINT插入的行数8insert_timeUBIGINTINSERT请求处理耗时微秒9insert_bytesUBIGINTINSERT请求报文大小字节10fetch_bytesUBIGINT查询结果大小字节11query_timeUBIGINT查询请求处理耗时12slow_queryUBIGINT慢查询次数处理耗时 ≥ 3 秒13total_reqUBIGINT请求总数14current_reqUBIGINT当前正在处理的请求数15last_accessTIMESTAMP最近一次更新时间慢查询计数是怎么来的文档将slow_query定义为“处理耗时 ≥ 3 秒”的查询次数但从源码看实际阈值并不是硬编码的服务端通过slowLogThreshold配置项下发阈值客户端在请求完成时按该阈值累加计数。在 source/common/src/tglobal.c 中当前仓库的默认值是int32_t tsSlowLogThreshold 10; // seconds char tsSlowLogExceptDb[TSDB_DB_NAME_LEN] ; // seconds int32_t tsSlowLogScope SLOW_LOG_TYPE_QUERY; int32_t tsSlowLogMaxLen 4096;与之配套的还有slowLogScope默认只统计查询、slowLogMaxLen慢 SQL 日志最大长度默认 4096、slowLogExceptDb排除的库等全局配置均在 source/common/src/tglobal.c 中注册CFG_SCOPE_SERVER/CFG_DYN_SERVER即服务端动态参数。统计动作发生在客户端侧请求结束时source/client/src/clientEnv.c 会比较请求耗时与服务器下发的阈值命中则对numOfSlowQueries做原子自增并视slowLogScope决定是否打印慢日志if ((duration pTscObj-pAppInfo-serverCfg.monitorParas.tsSlowLogThreshold * 1000000UL) checkSlowLogExceptDb(pRequest, pTscObj-pAppInfo-serverCfg.monitorParas.tsSlowLogExceptDb)) { (void)atomic_add_fetch_64((int64_t *)pActivity-numOfSlowQueries, 1); ... taosPrintSlowLog(PID:%d, connId:%u, QID:0x% PRIx64 , ..., ...); }这些统计随心跳批量上报给服务端并由 mnode 汇总进PERF_APPS心跳聚合逻辑见 source/client/src/clientHb.c上报消息的编码/解码见 source/common/src/msg/tmsg.c。因此在解读slow_query时应以其实际生效的服务端slowLogThreshold为准文档中的“3 秒”是默认语义描述。三、PERF_CONNECTIONS当前数据库连接PERF_CONNECTIONS提供当前数据库连接的用户、客户端、登录时间、连接类型与 token 信息。适合做“谁在连、从哪连、用什么版本连”的接入审计也可以用SHOW CONNECTIONS查看。#列名数据类型说明1conn_idUINT连接 ID2userBINARY(24)用户名。关键字列查询需用反引号转义如user3appBINARY(24)客户端名称4pidUINT发起连接的客户端进程 ID5end_pointBINARY(134)客户端地址6login_timeTIMESTAMP登录时间7last_accessTIMESTAMP最近更新时间8user_appBINARY(24)用户侧应用名9user_ipVARCHAR(22)用户侧 IP10native_versionBINARY(32)native 客户端版本11connector_infoBINARY(256)连接器信息12typeBINARY(16)连接类型13tokenBINARY(32)使用 token 登录时的 token 名称使用注意user是关键字列查询时必须写成user否则会报语法错误conn_id有实际运维价值配合KILL CONNECTION可以定向断开异常连接该表的列结构定义在 source/common/src/systable.c 附近的connectionsSchema中mnode 侧由 profile 管理模块维护连接缓存connCache相关单元测试见 source/dnode/mnode/impl/test/profile/profile.cpp通过TSDB_MGMT_TABLE_CONNS消息查询perf_connections并断言返回行数。四、PERF_CONSUMERS数据订阅消费者PERF_CONSUMERS提供数据订阅场景下每个消费者的消费组、状态、订阅主题、参数和最近 poll 时间是排查 TMQ数据订阅消费停滞、rebalance 频繁等问题的主要入口也可以用SHOW CONSUMERS查看。#列名数据类型说明1consumer_idBINARY(32)唯一消费者 ID2consumer_groupBINARY(193)消费组3client_idBINARY(256)创建消费者时指定的客户端标识4userBINARY(24)用户名5fqdnBINARY(128)消费者所在机器的 FQDN6statusBINARY(20)当前状态ready可用、lost连接丢失、rebalancingvgroup 分配中、unknown7topicsBINARY(205)订阅的主题多个主题显示为多行8end_pointVARCHAR(22)端点9up_timeTIMESTAMP首次连接taosd的时间10subscribe_timeTIMESTAMP最近一次订阅请求时间11rebalance_timeTIMESTAMP最近一次 rebalance 时间12parametersBINARY(192)订阅参数13poll_timeTIMESTAMP最近一次 poll 时间状态判读ready消费者可正常拉取数据lost连接已丢失通常意味着消费者进程异常退出或网络中断rebalancing消费组内 vgroup 正在重新分配属于过渡状态unknown状态未知需要结合up_time、subscribe_time、poll_time综合判断。一个实用的判读技巧若某消费者的poll_time远早于当前时间说明该消费者已停止拉取可能存在消费阻塞若rebalance_time频繁刷新说明消费组拓扑在抖动需要检查消费者的注册与心跳。五、PERF_INSTANCES实例注册信息PERF_INSTANCES提供接入集群的实例注册信息包括类型、描述、首次注册/最近注册时间和过期时间。这 6 张表里它是唯一标记为特权类PRIV_CAT_PRIVILEGED的表也可以用SHOW INSTANCES查看支持LIKE模式匹配。#列名数据类型说明1idVARCHAR(257)ID2typeVARCHAR(66)类型3descVARCHAR(514)实例描述4first_reg_timeTIMESTAMP首次注册时间5last_reg_timeTIMESTAMP最近一次注册时间6expireINT过期时间秒该表常用于确认各类分析/扩展实例是否在集群中正常注册、注册是否过期。若expire为 0 或last_reg_time长期不刷新通常说明实例心跳异常。六、PERF_QUERIES正在执行的查询PERF_QUERIES提供当前正在执行的查询的标识、耗时、阶段状态和 SQL 文本。这里的 “QUERIES” 按系统内部 API 命名习惯实际涵盖进行中的写入update、查询和删除操作。它也是SHOW QUERIES的数据来源。#列名数据类型说明1kill_idVARCHAR(26)配合KILL QUERY使用的 ID2query_idUBIGINT查询 ID3conn_idUINT连接 ID4appVARCHAR(24)应用名5pidINT应用在其主机上的进程 ID6userVARCHAR(24)用户名7end_pointVARCHAR(22)客户端地址8create_timeTIMESTAMP创建时间9exec_usecBIGINT已执行耗时微秒10stable_queryBOOL是否为超级表查询11sub_queryBOOL是否为子查询12sub_numINT子查询数量13sub_statusVARCHAR(1000)子查询状态含子查询 ID、状态及状态起始时间14sqlVARCHAR(2048)SQL 语句。关键字列查询需用反引号转义15user_appVARCHAR(24)用户侧应用名16user_ipVARCHAR(22)用户侧 IP17phase_stateVARCHAR(64)当前查询阶段/状态18phase_start_timeTIMESTAMP当前阶段的起始时间定位并终止慢查询kill_id正是为终止操作设计的从KILL QUERY的使用说明 可知获取方式如下-- 找到目标慢查询 SELECT kill_id, user, sql, exec_usec FROM performance_schema.perf_queries; -- 终止指定查询 KILL QUERY kill_id;phase_state与phase_start_time是排查“卡住”的关键如果某个查询的phase_state长时间不变化说明它停留在某一执行阶段如扫描、聚合、结果下发可结合exec_usec和sub_status判断瓶颈在哪个子任务。该表同样有对应的源码与测试支撑列结构定义于 source/common/src/systable.c 的querySchemamnode 单元测试 source/dnode/mnode/impl/test/profile/profile.cpp 通过TSDB_MGMT_TABLE_QUERIES消息查询perf_queries并验证结果行数。七、PERF_TRANS正在执行的元数据事务PERF_TRANS提供当前正在执行的元数据事务的阶段、操作对象、失败次数与最近执行详情。TDengine 的元数据变更建库、建表、超级表操作等以事务方式在 mnode 上执行该视图让你看到事务推进到哪一步、是否反复失败也可以使用SHOW TRANSACTIONS或SHOW TRANSACTION transaction_id查看指定事务的动作明细获取同类信息。#列名数据类型说明1idBIGINT事务 ID2create_timeTIMESTAMP创建时间3stageVARCHAR(12)当前阶段如redoAction、undoAction、commit4operVARCHAR(22)操作符5dbVARCHAR(64)相关数据库6stableVARCHAR(192)相关超级表7killableVARCHAR(10)事务是否可被终止8failed_timesINT累计执行失败次数9last_exec_timeTIMESTAMP最近一次执行时间10last_action_infoVARCHAR(511)最近一次失败执行的详情11typeVARCHAR(10)事务类型判读要点stage告诉你事务处于哪个动作阶段redoAction重做、undoAction回滚、commit提交等failed_times 0且持续增长、last_action_info有内容说明该元数据事务在反复重试通常是集群中某节点不可达或元数据不一致的信号killable标识该事务是否允许被终止为SHOW TRANSACTION/ 相关终止操作提供依据。八、组合查询实战把性能视图用起来1. 定位写入热点应用SELECT name, ip, insert_req, insert_row, insert_bytes, insert_time / 1000.0 AS insert_time_ms FROM performance_schema.perf_apps ORDER BY insert_row DESC;2. 找出结果集最大、最耗时的查询SELECT kill_id, user, sql, exec_usec / 1000.0 AS exec_ms, phase_state, phase_start_time FROM performance_schema.perf_queries ORDER BY exec_usec DESC;3. 审计当前连接与客户端版本SELECT user, app, pid, end_point, login_time, native_version, connector_info, type FROM performance_schema.perf_connections;4. 检查订阅消费是否停滞SELECT consumer_id, consumer_group, user, fqdn, status, topics, poll_time, subscribe_time FROM performance_schema.perf_consumers WHERE status ready;5. 查看元数据事务是否卡死SELECT id, stage, oper, db, stable, killable, failed_times, last_exec_time, last_action_info FROM performance_schema.perf_trans WHERE failed_times 0;以上查询均可在任意已授权的客户端执行若不想带库名前缀可先执行USE performance_schema;。需要强调这些视图是内存中的实时快照同一时刻不同查询可能看到稍有不同的数据适合做瞬时观测与趋势对比不应作为持久化监控指标的唯一来源持续采集建议接入监控组件。九、源码级实现速览一张 PERF 表是怎么“活”起来的综合仓库代码PERF_*视图的数据链路可以归纳为四层结构层表结构在 source/common/src/systable.c 的perfsMeta中静态声明每列的类型、字节长度、sysInfo标志并在 mnode 启动时由mndInitPerfs/mndPerfsInitMetasource/dnode/mnode/impl/src/mndPerfSchema.c装载进哈希表随查询动态返回表结构采集层客户端侧在请求处理中实时累计统计如慢查询计数、插入/查询耗时见 source/client/src/clientEnv.c上报层客户端统计随心跳打包上报source/client/src/clientHb.c服务端反序列化后写入 profile 管理模块的内存缓存mnode 侧连接/应用缓存由 source/dnode/mnode/impl/src/mndProfile.c 维护查询层执行器在扫描系统库时根据表名路由到对应元数据动态构建结果集见 source/libs/executor/src/sysscanoperator.c 对TSDB_PERFORMANCE_SCHEMA_DB的处理。需要特别说明的是include/common/systable.h 中还定义了perf_smas、perf_offsets、perf_write_metrics等表名常量但当前 perfsMeta 注册表 中对应的条目处于注释状态属于预留能力实际可查询的仍以本文 6 张表为准。这提醒我们在依赖某张系统表前先确认其在本版本中是否真正生效。十、与 INFORMATION_SCHEMA、SHOW 命令的配合想了解静态元数据库表结构、配置项、用户角色、vgroup 分布、磁盘占用查 INFORMATION_SCHEMA想了解运行时动态状态谁在查询、事务进度、连接与应用统计查本文的PERFORMANCE_SCHEMA两者都能覆盖的信息也可以用对应的 SHOW 命令 快速查看例如SHOW APPS、SHOW CONNECTIONS、SHOW CONSUMERS、SHOW QUERIES、SHOW INSTANCES、SHOW TRANSACTIONS。PERFORMANCE_SCHEMA将运行态信息统一收敛为可过滤、可排序、可聚合的标准 SQL 视图是 TDengine 运维与故障排查中最直接的一手数据来源。掌握这 6 张表的结构与语义再结合KILL QUERY、KILL CONNECTION等治理手段即可构建一套轻量、高效的运行时观测工作流。【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TDengine 内建性能库 PERFORMANCE_SCHEMA 全解：PERF_* 视图字段、权限与运行时观测实战
TDengine 内建性能库 PERFORMANCE_SCHEMA 全解PERF_* 视图字段、权限与运行时观测实战【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengineTDengine 从v3.0.0.0起内置了只读数据库PERFORMANCE_SCHEMA以标准 SQL 视图形式对外暴露集群运行时的性能与状态数据客户端应用、连接、订阅消费者、执行中查询、实例注册与元数据事务。本文将逐表解析PERF_*的全部字段含义与数据类型结合仓库源码说明慢查询统计、心跳上报、权限分类等底层实现并给出可直接落地的排查实战 SQL帮助你在不侵入业务的前提下完成运行时观测与问题定位。一、PERFORMANCE_SCHEMA 是什么PERFORMANCE_SCHEMA是 TDengine 自带的系统数据库专门用于存放与性能相关的统计视图。它与另一套系统库INFORMATION_SCHEMA见 元数据信息INFORMATION_SCHEMA互为补充前者侧重运行时动态状态谁在连接、谁在查询、事务进行到哪一步后者侧重元数据与静态配置库表结构、配置项、用户权限等。同时这些视图中的大部分信息也都可以通过对应的 SHOW 命令 获取。从源码结构看PERFORMANCE_SCHEMA属于典型的“视图而非基表”设计它没有独立的数据文件数据由 mnode管理节点在内存中实时汇总仅支持查询、不支持INSERT等写入操作。其元数据由管理节点初始化时统一注册数据库名与表名常量定义在 include/common/systable.h其中TSDB_PERFORMANCE_SCHEMA_DB即performance_schema各表的列结构SSysDbTableSchema数组定义在 source/common/src/systable.c 的perfsMeta注册表中管理节点在启动时通过mndPerfsInitMeta把这些表结构装载进内存哈希并支持按表名动态返回表结构见 source/dnode/mnode/impl/src/mndPerfSchema.c。你甚至可以直接USE performance_schema把它设为默认库mnode 在 source/dnode/mnode/impl/src/mndDb.c 中对USE performance_schema做了专门处理之后用熟悉的SELECT语法查询并可使用过滤、排序、聚合等全部 TDengine SQL 能力。权限与可见性每个系统表在注册时都带有一个权限分类。当前 6 张PERF_*表中除PERF_INSTANCES属于PRIV_CAT_PRIVILEGED特权类外其余均属于PRIV_CAT_BASIC基础类见 include/common/systable.h 与 source/common/src/systable.c。这意味着普通用户默认可以查询大部分性能视图但部分节点级、实例级信息如PERF_INSTANCES会受到更严格的权限约束。当前已注册的表虽然头文件中定义了perf_smas、perf_offsets、perf_write_metrics等更多表名常量但从 source/common/src/systable.c 的注册表看当前实际生效的共有 6 张表表名主题PERF_APPS连接集群的客户端应用统计PERF_CONNECTIONS当前数据库连接PERF_CONSUMERS数据订阅消费者PERF_INSTANCES接入集群的实例注册信息PERF_QUERIES正在执行的查询PERF_TRANS正在执行的元数据事务二、PERF_APPS客户端应用的写入与查询统计PERF_APPS针对连接到集群的每个应用客户端提供写入/查询统计、慢查询计数和最近访问时间。它可以回答“哪个客户端在狂写”“哪个客户端的查询最慢、结果集最大”这类问题也可以直接用SHOW APPS查看同一份数据。#列名数据类型说明1app_idUBIGINT客户端 ID2ipVARCHAR(16)客户端地址3pidINT客户端进程 ID4nameVARCHAR(24)客户端名称5start_timeTIMESTAMP客户端启动时间6insert_reqUBIGINTINSERT请求次数7insert_rowUBIGINT插入的行数8insert_timeUBIGINTINSERT请求处理耗时微秒9insert_bytesUBIGINTINSERT请求报文大小字节10fetch_bytesUBIGINT查询结果大小字节11query_timeUBIGINT查询请求处理耗时12slow_queryUBIGINT慢查询次数处理耗时 ≥ 3 秒13total_reqUBIGINT请求总数14current_reqUBIGINT当前正在处理的请求数15last_accessTIMESTAMP最近一次更新时间慢查询计数是怎么来的文档将slow_query定义为“处理耗时 ≥ 3 秒”的查询次数但从源码看实际阈值并不是硬编码的服务端通过slowLogThreshold配置项下发阈值客户端在请求完成时按该阈值累加计数。在 source/common/src/tglobal.c 中当前仓库的默认值是int32_t tsSlowLogThreshold 10; // seconds char tsSlowLogExceptDb[TSDB_DB_NAME_LEN] ; // seconds int32_t tsSlowLogScope SLOW_LOG_TYPE_QUERY; int32_t tsSlowLogMaxLen 4096;与之配套的还有slowLogScope默认只统计查询、slowLogMaxLen慢 SQL 日志最大长度默认 4096、slowLogExceptDb排除的库等全局配置均在 source/common/src/tglobal.c 中注册CFG_SCOPE_SERVER/CFG_DYN_SERVER即服务端动态参数。统计动作发生在客户端侧请求结束时source/client/src/clientEnv.c 会比较请求耗时与服务器下发的阈值命中则对numOfSlowQueries做原子自增并视slowLogScope决定是否打印慢日志if ((duration pTscObj-pAppInfo-serverCfg.monitorParas.tsSlowLogThreshold * 1000000UL) checkSlowLogExceptDb(pRequest, pTscObj-pAppInfo-serverCfg.monitorParas.tsSlowLogExceptDb)) { (void)atomic_add_fetch_64((int64_t *)pActivity-numOfSlowQueries, 1); ... taosPrintSlowLog(PID:%d, connId:%u, QID:0x% PRIx64 , ..., ...); }这些统计随心跳批量上报给服务端并由 mnode 汇总进PERF_APPS心跳聚合逻辑见 source/client/src/clientHb.c上报消息的编码/解码见 source/common/src/msg/tmsg.c。因此在解读slow_query时应以其实际生效的服务端slowLogThreshold为准文档中的“3 秒”是默认语义描述。三、PERF_CONNECTIONS当前数据库连接PERF_CONNECTIONS提供当前数据库连接的用户、客户端、登录时间、连接类型与 token 信息。适合做“谁在连、从哪连、用什么版本连”的接入审计也可以用SHOW CONNECTIONS查看。#列名数据类型说明1conn_idUINT连接 ID2userBINARY(24)用户名。关键字列查询需用反引号转义如user3appBINARY(24)客户端名称4pidUINT发起连接的客户端进程 ID5end_pointBINARY(134)客户端地址6login_timeTIMESTAMP登录时间7last_accessTIMESTAMP最近更新时间8user_appBINARY(24)用户侧应用名9user_ipVARCHAR(22)用户侧 IP10native_versionBINARY(32)native 客户端版本11connector_infoBINARY(256)连接器信息12typeBINARY(16)连接类型13tokenBINARY(32)使用 token 登录时的 token 名称使用注意user是关键字列查询时必须写成user否则会报语法错误conn_id有实际运维价值配合KILL CONNECTION可以定向断开异常连接该表的列结构定义在 source/common/src/systable.c 附近的connectionsSchema中mnode 侧由 profile 管理模块维护连接缓存connCache相关单元测试见 source/dnode/mnode/impl/test/profile/profile.cpp通过TSDB_MGMT_TABLE_CONNS消息查询perf_connections并断言返回行数。四、PERF_CONSUMERS数据订阅消费者PERF_CONSUMERS提供数据订阅场景下每个消费者的消费组、状态、订阅主题、参数和最近 poll 时间是排查 TMQ数据订阅消费停滞、rebalance 频繁等问题的主要入口也可以用SHOW CONSUMERS查看。#列名数据类型说明1consumer_idBINARY(32)唯一消费者 ID2consumer_groupBINARY(193)消费组3client_idBINARY(256)创建消费者时指定的客户端标识4userBINARY(24)用户名5fqdnBINARY(128)消费者所在机器的 FQDN6statusBINARY(20)当前状态ready可用、lost连接丢失、rebalancingvgroup 分配中、unknown7topicsBINARY(205)订阅的主题多个主题显示为多行8end_pointVARCHAR(22)端点9up_timeTIMESTAMP首次连接taosd的时间10subscribe_timeTIMESTAMP最近一次订阅请求时间11rebalance_timeTIMESTAMP最近一次 rebalance 时间12parametersBINARY(192)订阅参数13poll_timeTIMESTAMP最近一次 poll 时间状态判读ready消费者可正常拉取数据lost连接已丢失通常意味着消费者进程异常退出或网络中断rebalancing消费组内 vgroup 正在重新分配属于过渡状态unknown状态未知需要结合up_time、subscribe_time、poll_time综合判断。一个实用的判读技巧若某消费者的poll_time远早于当前时间说明该消费者已停止拉取可能存在消费阻塞若rebalance_time频繁刷新说明消费组拓扑在抖动需要检查消费者的注册与心跳。五、PERF_INSTANCES实例注册信息PERF_INSTANCES提供接入集群的实例注册信息包括类型、描述、首次注册/最近注册时间和过期时间。这 6 张表里它是唯一标记为特权类PRIV_CAT_PRIVILEGED的表也可以用SHOW INSTANCES查看支持LIKE模式匹配。#列名数据类型说明1idVARCHAR(257)ID2typeVARCHAR(66)类型3descVARCHAR(514)实例描述4first_reg_timeTIMESTAMP首次注册时间5last_reg_timeTIMESTAMP最近一次注册时间6expireINT过期时间秒该表常用于确认各类分析/扩展实例是否在集群中正常注册、注册是否过期。若expire为 0 或last_reg_time长期不刷新通常说明实例心跳异常。六、PERF_QUERIES正在执行的查询PERF_QUERIES提供当前正在执行的查询的标识、耗时、阶段状态和 SQL 文本。这里的 “QUERIES” 按系统内部 API 命名习惯实际涵盖进行中的写入update、查询和删除操作。它也是SHOW QUERIES的数据来源。#列名数据类型说明1kill_idVARCHAR(26)配合KILL QUERY使用的 ID2query_idUBIGINT查询 ID3conn_idUINT连接 ID4appVARCHAR(24)应用名5pidINT应用在其主机上的进程 ID6userVARCHAR(24)用户名7end_pointVARCHAR(22)客户端地址8create_timeTIMESTAMP创建时间9exec_usecBIGINT已执行耗时微秒10stable_queryBOOL是否为超级表查询11sub_queryBOOL是否为子查询12sub_numINT子查询数量13sub_statusVARCHAR(1000)子查询状态含子查询 ID、状态及状态起始时间14sqlVARCHAR(2048)SQL 语句。关键字列查询需用反引号转义15user_appVARCHAR(24)用户侧应用名16user_ipVARCHAR(22)用户侧 IP17phase_stateVARCHAR(64)当前查询阶段/状态18phase_start_timeTIMESTAMP当前阶段的起始时间定位并终止慢查询kill_id正是为终止操作设计的从KILL QUERY的使用说明 可知获取方式如下-- 找到目标慢查询 SELECT kill_id, user, sql, exec_usec FROM performance_schema.perf_queries; -- 终止指定查询 KILL QUERY kill_id;phase_state与phase_start_time是排查“卡住”的关键如果某个查询的phase_state长时间不变化说明它停留在某一执行阶段如扫描、聚合、结果下发可结合exec_usec和sub_status判断瓶颈在哪个子任务。该表同样有对应的源码与测试支撑列结构定义于 source/common/src/systable.c 的querySchemamnode 单元测试 source/dnode/mnode/impl/test/profile/profile.cpp 通过TSDB_MGMT_TABLE_QUERIES消息查询perf_queries并验证结果行数。七、PERF_TRANS正在执行的元数据事务PERF_TRANS提供当前正在执行的元数据事务的阶段、操作对象、失败次数与最近执行详情。TDengine 的元数据变更建库、建表、超级表操作等以事务方式在 mnode 上执行该视图让你看到事务推进到哪一步、是否反复失败也可以使用SHOW TRANSACTIONS或SHOW TRANSACTION transaction_id查看指定事务的动作明细获取同类信息。#列名数据类型说明1idBIGINT事务 ID2create_timeTIMESTAMP创建时间3stageVARCHAR(12)当前阶段如redoAction、undoAction、commit4operVARCHAR(22)操作符5dbVARCHAR(64)相关数据库6stableVARCHAR(192)相关超级表7killableVARCHAR(10)事务是否可被终止8failed_timesINT累计执行失败次数9last_exec_timeTIMESTAMP最近一次执行时间10last_action_infoVARCHAR(511)最近一次失败执行的详情11typeVARCHAR(10)事务类型判读要点stage告诉你事务处于哪个动作阶段redoAction重做、undoAction回滚、commit提交等failed_times 0且持续增长、last_action_info有内容说明该元数据事务在反复重试通常是集群中某节点不可达或元数据不一致的信号killable标识该事务是否允许被终止为SHOW TRANSACTION/ 相关终止操作提供依据。八、组合查询实战把性能视图用起来1. 定位写入热点应用SELECT name, ip, insert_req, insert_row, insert_bytes, insert_time / 1000.0 AS insert_time_ms FROM performance_schema.perf_apps ORDER BY insert_row DESC;2. 找出结果集最大、最耗时的查询SELECT kill_id, user, sql, exec_usec / 1000.0 AS exec_ms, phase_state, phase_start_time FROM performance_schema.perf_queries ORDER BY exec_usec DESC;3. 审计当前连接与客户端版本SELECT user, app, pid, end_point, login_time, native_version, connector_info, type FROM performance_schema.perf_connections;4. 检查订阅消费是否停滞SELECT consumer_id, consumer_group, user, fqdn, status, topics, poll_time, subscribe_time FROM performance_schema.perf_consumers WHERE status ready;5. 查看元数据事务是否卡死SELECT id, stage, oper, db, stable, killable, failed_times, last_exec_time, last_action_info FROM performance_schema.perf_trans WHERE failed_times 0;以上查询均可在任意已授权的客户端执行若不想带库名前缀可先执行USE performance_schema;。需要强调这些视图是内存中的实时快照同一时刻不同查询可能看到稍有不同的数据适合做瞬时观测与趋势对比不应作为持久化监控指标的唯一来源持续采集建议接入监控组件。九、源码级实现速览一张 PERF 表是怎么“活”起来的综合仓库代码PERF_*视图的数据链路可以归纳为四层结构层表结构在 source/common/src/systable.c 的perfsMeta中静态声明每列的类型、字节长度、sysInfo标志并在 mnode 启动时由mndInitPerfs/mndPerfsInitMetasource/dnode/mnode/impl/src/mndPerfSchema.c装载进哈希表随查询动态返回表结构采集层客户端侧在请求处理中实时累计统计如慢查询计数、插入/查询耗时见 source/client/src/clientEnv.c上报层客户端统计随心跳打包上报source/client/src/clientHb.c服务端反序列化后写入 profile 管理模块的内存缓存mnode 侧连接/应用缓存由 source/dnode/mnode/impl/src/mndProfile.c 维护查询层执行器在扫描系统库时根据表名路由到对应元数据动态构建结果集见 source/libs/executor/src/sysscanoperator.c 对TSDB_PERFORMANCE_SCHEMA_DB的处理。需要特别说明的是include/common/systable.h 中还定义了perf_smas、perf_offsets、perf_write_metrics等表名常量但当前 perfsMeta 注册表 中对应的条目处于注释状态属于预留能力实际可查询的仍以本文 6 张表为准。这提醒我们在依赖某张系统表前先确认其在本版本中是否真正生效。十、与 INFORMATION_SCHEMA、SHOW 命令的配合想了解静态元数据库表结构、配置项、用户角色、vgroup 分布、磁盘占用查 INFORMATION_SCHEMA想了解运行时动态状态谁在查询、事务进度、连接与应用统计查本文的PERFORMANCE_SCHEMA两者都能覆盖的信息也可以用对应的 SHOW 命令 快速查看例如SHOW APPS、SHOW CONNECTIONS、SHOW CONSUMERS、SHOW QUERIES、SHOW INSTANCES、SHOW TRANSACTIONS。PERFORMANCE_SCHEMA将运行态信息统一收敛为可过滤、可排序、可聚合的标准 SQL 视图是 TDengine 运维与故障排查中最直接的一手数据来源。掌握这 6 张表的结构与语义再结合KILL QUERY、KILL CONNECTION等治理手段即可构建一套轻量、高效的运行时观测工作流。【免费下载链接】TDengineHigh-performance, scalable time-series database designed for Industrial IoT (IIoT) scenarios项目地址: https://gitcode.com/GitHub_Trending/tde/TDengine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考