尧图网页设计 
Chat2DB MySQL 活动事务巡检基于 MYSQL-OPS-002 测试夹具的 Active Transactions 功能验证指南【免费下载链接】Chat2DBChat2DB is a free, cross-platform, local-first database client and SQL workspace for developers, DBAs, analysts, and data teams. Connect to 40 databases, manage data, edit and run SQL, and use your own AI model to generate, explain, and optimize queries. Available on desktop, web, Docker, and CLI, with MCP support.项目地址: https://gitcode.com/GitHub_Trending/ch/Chat2DB本指南围绕 Chat2DB 开源仓库中的 MySQL 操作测试夹具script/test-fixtures/mysql/MYSQL-OPS-002展开完整讲解其init.sql/grants.sql/cleanup.sql三个 SQL 文件的用途以及 README 中 12 步验证流程背后的功能逻辑与权限模型。读完本文你将掌握如何在 Chat2DB 中搭建管理员全量可见 受限用户降级可见的双账号 MySQL 测试环境通过 Active Transactions 视图检查 RUNNING / LOCK WAIT 状态、锁等待与阻塞链、会话跳转等能力并理解其底层基于information_schema与performance_schema的查询实现与降级策略。一、夹具背景MYSQL-OPS-002 要验证什么MYSQL-OPS-002 是 Chat2DB 仓库script/test-fixtures/mysql/目录下用于验证MySQL 活动事务Active Transaction巡检能力的测试夹具。它回答的核心问题是Chat2DB 能否在数据源的 Monitor 节点下展示当前所有活动 InnoDB 事务及其 SQL当事务进入锁等待LOCK WAIT时能否展示等待锁 / 阻塞事务 / 阻塞会话的完整链路当连接账号没有 PROCESS 权限时视图是崩溃、显示空白还是以明确的不可用 / 需权限状态降级呈现该夹具对应的前端实现位于 ActiveTransactionsContent 组件后端实现位于 MysqlActiveTransactionManager验证的是真实可用的用户功能而非一次性脚本。二、夹具文件组成与数据设计目录script/test-fixtures/mysql/MYSQL-OPS-002/下共四个文件文件作用README.md验证目标、步骤与预期结果init.sql建库建表、写入示例数据、创建两个测试账号grants.sql仅给管理员账号授予 PROCESS 等权限cleanup.sql清理测试库与测试用户1. init.sql数据与环境初始化CREATE DATABASE IF NOT EXISTS ops002_test; USE ops002_test; CREATE TABLE IF NOT EXISTS ops002_accounts ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(64) NOT NULL, balance DECIMAL(12,2) NOT NULL DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB; INSERT INTO ops002_accounts (name, balance) VALUES (alice, 1000.00), (bob, 500.00), (carol, 250.00); CREATE USER IF NOT EXISTS ops002_admin% IDENTIFIED BY Ops002_admin_2026; CREATE USER IF NOT EXISTS ops002_user% IDENTIFIED BY Ops002_user_2026; GRANT SELECT, INSERT, UPDATE, DELETE ON ops002_test.* TO ops002_admin%; GRANT SELECT, INSERT, UPDATE, DELETE ON ops002_test.* TO ops002_user%;要点表ops002_accounts显式声明ENGINEInnoDB确保事务与行锁语义可用MyISAM 不支持事务预置 alice / bob / carol 三条账户记录DECIMAL(12,2)金额字段便于后续执行balance balance - 100之类的 UPDATE 制造锁两个账号对ops002_test库拥有相同的 DML 权限差异只体现在 PROCESS 权限上这是验证同数据、不同可见性的关键。2. grants.sql权限差异的根源GRANT PROCESS ON *.* TO ops002_admin%; GRANT SELECT ON performance_schema.data_lock_waits TO ops002_admin%; GRANT SELECT ON performance_schema.data_locks TO ops002_admin%; FLUSH PRIVILEGES;权限模型一目了然ops002_admin拥有PROCESS全局权限可查看所有用户的线程/事务及 SQL 文本同时显式授予对performance_schema.data_lock_waits与data_locks的 SELECT用于 MySQL 8.0 锁等待元数据ops002_user故意不授予PROCESS。按 MySQL 权限检查规则跨用户的事务/进程细节可能被隐藏、SQL 文本返回 NULL甚至整个活动事务查询被拒绝。3. cleanup.sql一键清理DROP DATABASE IF EXISTS ops002_test; DROP USER IF EXISTS ops002_admin%; DROP USER IF EXISTS ops002_user%;验证结束后执行清理避免污染测试环境。三、12 步验证流程详解README 的 Verification 部分给出了完整验证路径按管理员全量视角 → 锁等待链 → 受限用户降级视角 → 空状态四个阶段组织。阶段一管理员视角的全量事务列表步骤 1–5以ops002_admin连接数据源展开数据源的Monitor节点双击Active Transactions打开活动事务视图打开第二个连接执行并保持打开START TRANSACTION; UPDATE ops002_accounts SET balance balance - 100 WHERE id 1;刷新视图预期该事务出现并包含状态RUNNING、持续增长的事务年龄、隔离级别REPEATABLE READ、线程 ID、用户、主机、数据库以及 UPDATE SQL 文本打开第三个连接再开启第二个事务预期两个事务均被列出且按开始时间排序。前端实现印证了这些列index.tsx中定义了事务 ID、状态RUNNING / LOCK WAIT 可筛选、开始时间、年龄、隔离级别、锁定行数、修改行数、线程 ID、用户、主机、数据库、等待锁、阻塞者、查询文本等列其中年龄列每秒刷新——getLiveTransactionAge用快照时间加时间差实时推算见 activeTransactionUtils.ts。阶段二锁等待与阻塞链验证步骤 6–9在第三个连接执行此时第一个事务已持有 id1 的行锁START TRANSACTION; UPDATE ops002_accounts SET balance balance 10 WHERE id 1;预期等待事务状态变为LOCK WAIT。前端常量 activeTransaction.ts 中定义了MYSQL_ACTIVE_TRANSACTION_STATE { RUNNING: RUNNING, LOCK_WAIT: LOCK WAIT }与验证预期完全一致。MySQL 8.0 环境用以下 SQL 取证对应源码中performance_schema.data_lock_waits的映射SELECT REQUESTING_ENGINE_TRANSACTION_ID, REQUESTING_ENGINE_LOCK_ID, BLOCKING_ENGINE_TRANSACTION_ID, BLOCKING_ENGINE_LOCK_ID FROM performance_schema.data_lock_waits;MySQL 5.7 环境用以下 SQL 取证对应源码中information_schema.innodb_lock_waits的映射SELECT requesting_trx_id, requested_lock_id, blocking_trx_id, blocking_lock_id FROM information_schema.innodb_lock_waits;预期视图对等待行显示 waited-lock 与 blocker 字段且 owner 与 blocker 的连接 ID 可点击跳转到以information_schema.PROCESSLIST.ID精确过滤的数据源绑定控制台。前端getTransactionConnectionInspectionactiveTransactionUtils.ts按owner/blocker分别取出线程 ID 与预生成好的会话检查 SQL点击后通过onInspectConnection回调打开目标控制台。阶段三提交/回滚后消失步骤 10提交或回滚第一个事务并刷新预期该事务消失而非保留为历史行——视图只呈现当前活动事务快照语义与information_schema.innodb_trx一致。阶段四受限用户与空状态步骤 11–12以ops002_user连接并开启事务后刷新预期出现三类明确的降级呈现而不是报错或误导性空白MySQL 返回 NULL 时隐藏的 SQL 以显式不可用状态渲染账号或服务器无法暴露锁等待元数据时锁等待信息显式降级事务/进程查询被 PROCESS 权限拒绝时呈现需权限状态而非泛化的运行时错误。无任何活动事务时刷新预期正常显示空状态。四、源码级原理从点击到数据的完整链路1. 前端请求入口service/sql.ts 定义了请求export interface IActiveTransactionRequest { dataSourceId: number; databaseName?: string; schemaName?: string; } const getActiveTransactionList createRequestIActiveTransactionRequest, IActiveTransactionItem[]( /api/rdb/active_transaction/list, { method: get, errorLevel: false }, );组件加载时调用该接口并用beginLatestRequest/isLatestRequest机制丢弃过期请求的响应防止连续刷新时旧数据覆盖新数据页面卸载时调用invalidateActiveTransactionRefresh作废在途请求。2. 后端 SPI 与 MySQL 实现功能按 Chat2DB 插件 SPI 体系实现接口 IActiveTransactionManager 定义能力MySQL 插件通过 MysqlPlugin 注册 MysqlActiveTransactionManager。MysqlActiveTransactionManager.activeTransactions()的核心流程源码约 L24-L42resolveLockMetadataQuery(connection) → 执行主查询 executeActiveTransactions │ │ │ 先探测 MySQL 8.0 data_lock_waits │ 若锁元数据缺失/被拒 │ 失败则探测 5.7 innodb_lock_waits │ → 降级重查(无锁元数据) │ 再失败则用不可用占位列 │ → 失败则 sanitize 异常主查询 SQL定义在 MysqlActiveTransactionConstants以information_schema.innodb_trx为驱动表SELECT t.trx_id, t.trx_state, t.trx_started, TIMESTAMPDIFF(SECOND, t.trx_started, NOW()) AS trx_age_seconds, t.trx_isolation_level, t.trx_rows_locked, t.trx_rows_modified, t.trx_lock_structs, t.trx_mysql_thread_id, p.ID AS process_id, p.USER AS process_user, p.HOST AS process_host, p.DB AS process_db, t.trx_query, %s -- 锁等待列(按版本注入) FROM information_schema.innodb_trx t LEFT JOIN information_schema.processlist p ON t.trx_mysql_thread_id p.ID %s -- 锁等待 JOIN(按版本注入) ORDER BY t.trx_started这正是 README 步骤 4按开始时间排序、步骤 5按开始时间排序以及年龄字段的由来——年龄直接用TIMESTAMPDIFF秒级计算。3. 双版本锁元数据探测步骤 7/8 的源码印证resolveLockMetadataQuery先执行探测 SQLSELECT 1 FROM performance_schema.data_lock_waits WHERE 1 0成功则采用 8.0 锁连接LOCK_JOIN_80通过data_lock_waitsLEFT JOINdata_locks获取等待/阻塞双方的对象、索引、锁类型、锁模式、锁状态与锁数据失败且错误属于缺失/被拒类别时降级探测information_schema.innodb_lock_waitsLOCK_JOIN_57LEFT JOINinnodb_locks再失败则使用全 NULL 占位列LOCK_COLUMNS_UNAVAILABLE事务主列表仍然可用只是锁等待信息变为不可用。错误识别由hasMissingOrDeniedMetadataError完成源码 L197-L210匹配 MySQL 错误码 1142表访问拒绝、1146表不存在、1227特定权限拒绝或消息中包含DATA_LOCK、INNODB_LOCK、PERFORMANCE_SCHEMA、COMMAND DENIED、DOESNT EXIST、DOES NOT EXIST、PROCESS等标记。4. 权限错误的显式化步骤 11 的实现基础当最终查询因缺少 PROCESS 权限被 MySQL 拒绝时sanitizeActiveTransactionQueryException源码 L212-L217将其包装为带错误码mysql.activeTransaction.processPrivilegeRequired的BusinessException。前端收到后classifyActiveTransactionLoadError 依据errorCode判定为PROCESS_PRIVILEGE_REQUIRED界面渲染permissionRequiredprocessPrivilegeHint提示文案见index.tsx的errorMessage逻辑而不是显示一段原始堆栈或空表。对返回NULL的 SQL 文本后端设置queryState UNAVAILABLE、前端按ActiveTransactionQueryState.UNAVAILABLE渲染查询不可用标签锁元数据不可用时组件顶部还会显示整体降级提示lockMetadataDegraded。5. 会话可用性与跳转步骤 9 的实现基础后端通过processlist.ID是否为 NULL 判断会话是否存在/可见sessionState为LIVE或DISAPPEARED_OR_HIDDEN仅当process_id与trx_mysql_thread_id都存在时才允许打开会话并生成会话检查 SQLSELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID %d;blockingThreadId/blockingProcessId同理决定 blocker 侧是否可跳转。前端的getTransactionConnectionInspection正是据此决定是否渲染可点击的打开会话按钮。五、测试保障单元测试对行为的固化仓库为上述行为提供了扎实的单元测试MysqlActiveTransactionManagerTest 验证跨异常包装识别 PROCESS 权限失败recognizesProcessPrivilegeFailuresThroughWrappedCauses、主查询包含 innodb_trx processlist JOIN 且按开始时间排序buildsLiveTransactionQueryWithMySql80LockWaitMetadata、锁元数据不可用时仍保留事务主数据源unavailableLockMetadataQueryKeepsLiveTransactionSource、错误码 1142/1146/1227 与消息标记识别recognizesMissingOrDeniedMetadataFailures、结果集到类型化事务响应的映射mapsResultSetToTypedTransactionResponseactiveTransactionUtils.test.ts 覆盖前端的行 key 生成、错误分类与年龄计算服务端 DbActiveTransactionServiceImplTest 覆盖服务层聚合逻辑。这些测试与 MYSQL-OPS-002 夹具互为印证单元测试锁定单测行为夹具在真实 MySQL 8.0 / 5.7 上验证端到端表现。六、运行与清理建议初始化以具备建库建权权限的管理员在 MySQL 上依次执行 init.sql 与 grants.sql验证按 README 的 12 步流程在 Chat2DB 中分别用ops002_admin与ops002_user连接ops002_test库进入 Monitor → Active Transactions 执行各阶段检查清理验证完成后执行 cleanup.sql 删除测试库与两个测试账号版本前提步骤 7/8 分别面向 MySQL 8.0performance_schema与 5.7information_schema取证视图自身通过探测自动选择元数据来源见 ActiveTransaction.LockMetadataSource 枚举MYSQL_80_PERFORMANCE_SCHEMA/MYSQL_57_INFORMATION_SCHEMA。七、总结MYSQL-OPS-002 夹具完整覆盖了 Chat2DB Active Transactions 功能的三条核心路径全量可见PROCESS 权限下的事务 SQL 锁等待链、显式降级无权限时以需权限 / 不可用状态呈现而非报错、空状态无事务时的正常展示。配合源码可以确认从information_schema.innodb_trx驱动查询、data_lock_waits/innodb_lock_waits双版本探测、PROCESSLIST.ID会话跳转到前端错误分类与逐秒刷新的年龄显示整条链路在前后端与测试中都有据可查。将这套夹具用于你的 MySQL 环境即可系统性地验证并演示 Chat2DB 的活动事务巡检能力。【免费下载链接】Chat2DBChat2DB is a free, cross-platform, local-first database client and SQL workspace for developers, DBAs, analysts, and data teams. Connect to 40 databases, manage data, edit and run SQL, and use your own AI model to generate, explain, and optimize queries. Available on desktop, web, Docker, and CLI, with MCP support.项目地址: https://gitcode.com/GitHub_Trending/ch/Chat2DB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Chat2DB MySQL 活动事务巡检：基于 MYSQL-OPS-002 测试夹具的 Active Transactions 功能验证指南
Chat2DB MySQL 活动事务巡检基于 MYSQL-OPS-002 测试夹具的 Active Transactions 功能验证指南【免费下载链接】Chat2DBChat2DB is a free, cross-platform, local-first database client and SQL workspace for developers, DBAs, analysts, and data teams. Connect to 40 databases, manage data, edit and run SQL, and use your own AI model to generate, explain, and optimize queries. Available on desktop, web, Docker, and CLI, with MCP support.项目地址: https://gitcode.com/GitHub_Trending/ch/Chat2DB本指南围绕 Chat2DB 开源仓库中的 MySQL 操作测试夹具script/test-fixtures/mysql/MYSQL-OPS-002展开完整讲解其init.sql/grants.sql/cleanup.sql三个 SQL 文件的用途以及 README 中 12 步验证流程背后的功能逻辑与权限模型。读完本文你将掌握如何在 Chat2DB 中搭建管理员全量可见 受限用户降级可见的双账号 MySQL 测试环境通过 Active Transactions 视图检查 RUNNING / LOCK WAIT 状态、锁等待与阻塞链、会话跳转等能力并理解其底层基于information_schema与performance_schema的查询实现与降级策略。一、夹具背景MYSQL-OPS-002 要验证什么MYSQL-OPS-002 是 Chat2DB 仓库script/test-fixtures/mysql/目录下用于验证MySQL 活动事务Active Transaction巡检能力的测试夹具。它回答的核心问题是Chat2DB 能否在数据源的 Monitor 节点下展示当前所有活动 InnoDB 事务及其 SQL当事务进入锁等待LOCK WAIT时能否展示等待锁 / 阻塞事务 / 阻塞会话的完整链路当连接账号没有 PROCESS 权限时视图是崩溃、显示空白还是以明确的不可用 / 需权限状态降级呈现该夹具对应的前端实现位于 ActiveTransactionsContent 组件后端实现位于 MysqlActiveTransactionManager验证的是真实可用的用户功能而非一次性脚本。二、夹具文件组成与数据设计目录script/test-fixtures/mysql/MYSQL-OPS-002/下共四个文件文件作用README.md验证目标、步骤与预期结果init.sql建库建表、写入示例数据、创建两个测试账号grants.sql仅给管理员账号授予 PROCESS 等权限cleanup.sql清理测试库与测试用户1. init.sql数据与环境初始化CREATE DATABASE IF NOT EXISTS ops002_test; USE ops002_test; CREATE TABLE IF NOT EXISTS ops002_accounts ( id BIGINT NOT NULL AUTO_INCREMENT, name VARCHAR(64) NOT NULL, balance DECIMAL(12,2) NOT NULL DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB; INSERT INTO ops002_accounts (name, balance) VALUES (alice, 1000.00), (bob, 500.00), (carol, 250.00); CREATE USER IF NOT EXISTS ops002_admin% IDENTIFIED BY Ops002_admin_2026; CREATE USER IF NOT EXISTS ops002_user% IDENTIFIED BY Ops002_user_2026; GRANT SELECT, INSERT, UPDATE, DELETE ON ops002_test.* TO ops002_admin%; GRANT SELECT, INSERT, UPDATE, DELETE ON ops002_test.* TO ops002_user%;要点表ops002_accounts显式声明ENGINEInnoDB确保事务与行锁语义可用MyISAM 不支持事务预置 alice / bob / carol 三条账户记录DECIMAL(12,2)金额字段便于后续执行balance balance - 100之类的 UPDATE 制造锁两个账号对ops002_test库拥有相同的 DML 权限差异只体现在 PROCESS 权限上这是验证同数据、不同可见性的关键。2. grants.sql权限差异的根源GRANT PROCESS ON *.* TO ops002_admin%; GRANT SELECT ON performance_schema.data_lock_waits TO ops002_admin%; GRANT SELECT ON performance_schema.data_locks TO ops002_admin%; FLUSH PRIVILEGES;权限模型一目了然ops002_admin拥有PROCESS全局权限可查看所有用户的线程/事务及 SQL 文本同时显式授予对performance_schema.data_lock_waits与data_locks的 SELECT用于 MySQL 8.0 锁等待元数据ops002_user故意不授予PROCESS。按 MySQL 权限检查规则跨用户的事务/进程细节可能被隐藏、SQL 文本返回 NULL甚至整个活动事务查询被拒绝。3. cleanup.sql一键清理DROP DATABASE IF EXISTS ops002_test; DROP USER IF EXISTS ops002_admin%; DROP USER IF EXISTS ops002_user%;验证结束后执行清理避免污染测试环境。三、12 步验证流程详解README 的 Verification 部分给出了完整验证路径按管理员全量视角 → 锁等待链 → 受限用户降级视角 → 空状态四个阶段组织。阶段一管理员视角的全量事务列表步骤 1–5以ops002_admin连接数据源展开数据源的Monitor节点双击Active Transactions打开活动事务视图打开第二个连接执行并保持打开START TRANSACTION; UPDATE ops002_accounts SET balance balance - 100 WHERE id 1;刷新视图预期该事务出现并包含状态RUNNING、持续增长的事务年龄、隔离级别REPEATABLE READ、线程 ID、用户、主机、数据库以及 UPDATE SQL 文本打开第三个连接再开启第二个事务预期两个事务均被列出且按开始时间排序。前端实现印证了这些列index.tsx中定义了事务 ID、状态RUNNING / LOCK WAIT 可筛选、开始时间、年龄、隔离级别、锁定行数、修改行数、线程 ID、用户、主机、数据库、等待锁、阻塞者、查询文本等列其中年龄列每秒刷新——getLiveTransactionAge用快照时间加时间差实时推算见 activeTransactionUtils.ts。阶段二锁等待与阻塞链验证步骤 6–9在第三个连接执行此时第一个事务已持有 id1 的行锁START TRANSACTION; UPDATE ops002_accounts SET balance balance 10 WHERE id 1;预期等待事务状态变为LOCK WAIT。前端常量 activeTransaction.ts 中定义了MYSQL_ACTIVE_TRANSACTION_STATE { RUNNING: RUNNING, LOCK_WAIT: LOCK WAIT }与验证预期完全一致。MySQL 8.0 环境用以下 SQL 取证对应源码中performance_schema.data_lock_waits的映射SELECT REQUESTING_ENGINE_TRANSACTION_ID, REQUESTING_ENGINE_LOCK_ID, BLOCKING_ENGINE_TRANSACTION_ID, BLOCKING_ENGINE_LOCK_ID FROM performance_schema.data_lock_waits;MySQL 5.7 环境用以下 SQL 取证对应源码中information_schema.innodb_lock_waits的映射SELECT requesting_trx_id, requested_lock_id, blocking_trx_id, blocking_lock_id FROM information_schema.innodb_lock_waits;预期视图对等待行显示 waited-lock 与 blocker 字段且 owner 与 blocker 的连接 ID 可点击跳转到以information_schema.PROCESSLIST.ID精确过滤的数据源绑定控制台。前端getTransactionConnectionInspectionactiveTransactionUtils.ts按owner/blocker分别取出线程 ID 与预生成好的会话检查 SQL点击后通过onInspectConnection回调打开目标控制台。阶段三提交/回滚后消失步骤 10提交或回滚第一个事务并刷新预期该事务消失而非保留为历史行——视图只呈现当前活动事务快照语义与information_schema.innodb_trx一致。阶段四受限用户与空状态步骤 11–12以ops002_user连接并开启事务后刷新预期出现三类明确的降级呈现而不是报错或误导性空白MySQL 返回 NULL 时隐藏的 SQL 以显式不可用状态渲染账号或服务器无法暴露锁等待元数据时锁等待信息显式降级事务/进程查询被 PROCESS 权限拒绝时呈现需权限状态而非泛化的运行时错误。无任何活动事务时刷新预期正常显示空状态。四、源码级原理从点击到数据的完整链路1. 前端请求入口service/sql.ts 定义了请求export interface IActiveTransactionRequest { dataSourceId: number; databaseName?: string; schemaName?: string; } const getActiveTransactionList createRequestIActiveTransactionRequest, IActiveTransactionItem[]( /api/rdb/active_transaction/list, { method: get, errorLevel: false }, );组件加载时调用该接口并用beginLatestRequest/isLatestRequest机制丢弃过期请求的响应防止连续刷新时旧数据覆盖新数据页面卸载时调用invalidateActiveTransactionRefresh作废在途请求。2. 后端 SPI 与 MySQL 实现功能按 Chat2DB 插件 SPI 体系实现接口 IActiveTransactionManager 定义能力MySQL 插件通过 MysqlPlugin 注册 MysqlActiveTransactionManager。MysqlActiveTransactionManager.activeTransactions()的核心流程源码约 L24-L42resolveLockMetadataQuery(connection) → 执行主查询 executeActiveTransactions │ │ │ 先探测 MySQL 8.0 data_lock_waits │ 若锁元数据缺失/被拒 │ 失败则探测 5.7 innodb_lock_waits │ → 降级重查(无锁元数据) │ 再失败则用不可用占位列 │ → 失败则 sanitize 异常主查询 SQL定义在 MysqlActiveTransactionConstants以information_schema.innodb_trx为驱动表SELECT t.trx_id, t.trx_state, t.trx_started, TIMESTAMPDIFF(SECOND, t.trx_started, NOW()) AS trx_age_seconds, t.trx_isolation_level, t.trx_rows_locked, t.trx_rows_modified, t.trx_lock_structs, t.trx_mysql_thread_id, p.ID AS process_id, p.USER AS process_user, p.HOST AS process_host, p.DB AS process_db, t.trx_query, %s -- 锁等待列(按版本注入) FROM information_schema.innodb_trx t LEFT JOIN information_schema.processlist p ON t.trx_mysql_thread_id p.ID %s -- 锁等待 JOIN(按版本注入) ORDER BY t.trx_started这正是 README 步骤 4按开始时间排序、步骤 5按开始时间排序以及年龄字段的由来——年龄直接用TIMESTAMPDIFF秒级计算。3. 双版本锁元数据探测步骤 7/8 的源码印证resolveLockMetadataQuery先执行探测 SQLSELECT 1 FROM performance_schema.data_lock_waits WHERE 1 0成功则采用 8.0 锁连接LOCK_JOIN_80通过data_lock_waitsLEFT JOINdata_locks获取等待/阻塞双方的对象、索引、锁类型、锁模式、锁状态与锁数据失败且错误属于缺失/被拒类别时降级探测information_schema.innodb_lock_waitsLOCK_JOIN_57LEFT JOINinnodb_locks再失败则使用全 NULL 占位列LOCK_COLUMNS_UNAVAILABLE事务主列表仍然可用只是锁等待信息变为不可用。错误识别由hasMissingOrDeniedMetadataError完成源码 L197-L210匹配 MySQL 错误码 1142表访问拒绝、1146表不存在、1227特定权限拒绝或消息中包含DATA_LOCK、INNODB_LOCK、PERFORMANCE_SCHEMA、COMMAND DENIED、DOESNT EXIST、DOES NOT EXIST、PROCESS等标记。4. 权限错误的显式化步骤 11 的实现基础当最终查询因缺少 PROCESS 权限被 MySQL 拒绝时sanitizeActiveTransactionQueryException源码 L212-L217将其包装为带错误码mysql.activeTransaction.processPrivilegeRequired的BusinessException。前端收到后classifyActiveTransactionLoadError 依据errorCode判定为PROCESS_PRIVILEGE_REQUIRED界面渲染permissionRequiredprocessPrivilegeHint提示文案见index.tsx的errorMessage逻辑而不是显示一段原始堆栈或空表。对返回NULL的 SQL 文本后端设置queryState UNAVAILABLE、前端按ActiveTransactionQueryState.UNAVAILABLE渲染查询不可用标签锁元数据不可用时组件顶部还会显示整体降级提示lockMetadataDegraded。5. 会话可用性与跳转步骤 9 的实现基础后端通过processlist.ID是否为 NULL 判断会话是否存在/可见sessionState为LIVE或DISAPPEARED_OR_HIDDEN仅当process_id与trx_mysql_thread_id都存在时才允许打开会话并生成会话检查 SQLSELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID %d;blockingThreadId/blockingProcessId同理决定 blocker 侧是否可跳转。前端的getTransactionConnectionInspection正是据此决定是否渲染可点击的打开会话按钮。五、测试保障单元测试对行为的固化仓库为上述行为提供了扎实的单元测试MysqlActiveTransactionManagerTest 验证跨异常包装识别 PROCESS 权限失败recognizesProcessPrivilegeFailuresThroughWrappedCauses、主查询包含 innodb_trx processlist JOIN 且按开始时间排序buildsLiveTransactionQueryWithMySql80LockWaitMetadata、锁元数据不可用时仍保留事务主数据源unavailableLockMetadataQueryKeepsLiveTransactionSource、错误码 1142/1146/1227 与消息标记识别recognizesMissingOrDeniedMetadataFailures、结果集到类型化事务响应的映射mapsResultSetToTypedTransactionResponseactiveTransactionUtils.test.ts 覆盖前端的行 key 生成、错误分类与年龄计算服务端 DbActiveTransactionServiceImplTest 覆盖服务层聚合逻辑。这些测试与 MYSQL-OPS-002 夹具互为印证单元测试锁定单测行为夹具在真实 MySQL 8.0 / 5.7 上验证端到端表现。六、运行与清理建议初始化以具备建库建权权限的管理员在 MySQL 上依次执行 init.sql 与 grants.sql验证按 README 的 12 步流程在 Chat2DB 中分别用ops002_admin与ops002_user连接ops002_test库进入 Monitor → Active Transactions 执行各阶段检查清理验证完成后执行 cleanup.sql 删除测试库与两个测试账号版本前提步骤 7/8 分别面向 MySQL 8.0performance_schema与 5.7information_schema取证视图自身通过探测自动选择元数据来源见 ActiveTransaction.LockMetadataSource 枚举MYSQL_80_PERFORMANCE_SCHEMA/MYSQL_57_INFORMATION_SCHEMA。七、总结MYSQL-OPS-002 夹具完整覆盖了 Chat2DB Active Transactions 功能的三条核心路径全量可见PROCESS 权限下的事务 SQL 锁等待链、显式降级无权限时以需权限 / 不可用状态呈现而非报错、空状态无事务时的正常展示。配合源码可以确认从information_schema.innodb_trx驱动查询、data_lock_waits/innodb_lock_waits双版本探测、PROCESSLIST.ID会话跳转到前端错误分类与逐秒刷新的年龄显示整条链路在前后端与测试中都有据可查。将这套夹具用于你的 MySQL 环境即可系统性地验证并演示 Chat2DB 的活动事务巡检能力。【免费下载链接】Chat2DBChat2DB is a free, cross-platform, local-first database client and SQL workspace for developers, DBAs, analysts, and data teams. Connect to 40 databases, manage data, edit and run SQL, and use your own AI model to generate, explain, and optimize queries. Available on desktop, web, Docker, and CLI, with MCP support.项目地址: https://gitcode.com/GitHub_Trending/ch/Chat2DB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考