在知识库中专注阅读，并随时返回相关工具与课程
GoldenDB 是中兴通讯旗下金篆信科推出的金融级分布式数据库，提供分布式事务、分片、高可用、读写分离、备份恢复和运维管理等能力。其公开白皮书说明 GoldenDB 支持 SQL92/SQL99/SQL2003，并兼容 MySQL 常用语法，同时提供 OMM、Insight、Tool Suite 等管理工具。
GoldenDB 是中兴通讯旗下金篆信科推出的金融级分布式数据库，提供分布式事务、分片、高可用、读写分离、备份恢复和运维管理等能力。其公开白皮书说明 GoldenDB 支持 SQL92/SQL99/SQL2003，并兼容 MySQL 常用语法，同时提供 OMM、Insight、Tool Suite 等管理工具。
下面整理 100 条常用 SQL、客户端命令和巡检操作，覆盖连接、对象、事务、会话、性能、权限、备份及分布式集群检查。
需要特别说明：GoldenDB 不同版本、部署模式和兼容模式的系统视图、管理接口可能不同。本文前 80 条以公开资料确认的 MySQL 兼容能力和标准 SQL 为主；后 20 条涉及 GoldenDB 专有能力时，只给出公开可核验的 OMM/Insight 操作入口和检查目标，不虚构未公开的内部命令。生产环境请以对应版本产品手册和现场权限为准。
1mysql -h 192.168.1.10 -P 3306 -u dba -p地址和端口通常指向 GoldenDB 对外服务入口，不要绕过接入层直连数据节点。
1SELECT VERSION();1SELECT DATABASE();1SELECT CURRENT_USER(), USER();1SELECT NOW(), CURRENT_TIMESTAMP();1SHOW VARIABLES LIKE 'character_set%';1SHOW VARIABLES LIKE 'collation%';1SELECT @@SESSION.sql_mode, @@GLOBAL.sql_mode;1SELECT @@SESSION.time_zone, @@GLOBAL.time_zone;1SELECT CONNECTION_ID();1SHOW DATABASES;1CREATE DATABASE appdb2 DEFAULT CHARACTER SET utf8mb4;1USE appdb;1SHOW CREATE DATABASE appdb;1SHOW FULL TABLES FROM appdb;1DESC appdb.orders;1SHOW CREATE TABLE appdb.orders;1CREATE TABLE appdb.orders (2 order_id BIGINT NOT NULL,3 customer_id BIGINT NOT NULL,4 order_time DATETIME NOT NULL,5 amount DECIMAL(18,2) NOT NULL,6 status VARCHAR(20),7 PRIMARY KEY (order_id)8);分片键、分布方式及全局唯一性约束应按对应 GoldenDB 版本的建表规范补充。
1ALTER TABLE appdb.orders2 ADD COLUMN remark VARCHAR(200);1ALTER TABLE appdb.orders2 MODIFY COLUMN remark VARCHAR(500);1ALTER TABLE appdb.orders2 DROP COLUMN remark;1RENAME TABLE appdb.orders TO appdb.orders_history;1TRUNCATE TABLE appdb.orders_history;1DROP TABLE appdb.orders_history;1SHOW FULL TABLES FROM appdb WHERE Table_type = 'VIEW';1CREATE VIEW appdb.v_paid_orders AS2SELECT order_id, customer_id, amount3FROM appdb.orders4WHERE status = 'PAID';1SHOW PROCEDURE STATUS WHERE Db = 'appdb';1SHOW FUNCTION STATUS WHERE Db = 'appdb';1SHOW TRIGGERS FROM appdb;1SHOW EVENTS FROM appdb;1SELECT table_schema, table_name, table_type2FROM information_schema.tables3WHERE table_schema = 'appdb'4ORDER BY table_name;1SELECT column_name, column_type, is_nullable, column_key2FROM information_schema.columns3WHERE table_schema = 'appdb'4 AND table_name = 'orders'5ORDER BY ordinal_position;1SHOW INDEX FROM appdb.orders;1SELECT index_name, column_name, non_unique, seq_in_index2FROM information_schema.statistics3WHERE table_schema = 'appdb'4 AND table_name = 'orders'5ORDER BY index_name, seq_in_index;1CREATE INDEX idx_orders_customer2ON appdb.orders(customer_id);1CREATE INDEX idx_orders_status_time2ON appdb.orders(status, order_time);1DROP INDEX idx_orders_status_time2ON appdb.orders;1SELECT table_name,2 table_rows,3 data_length,4 index_length,5 data_free6FROM information_schema.tables7WHERE table_schema = 'appdb'8ORDER BY data_length + index_length DESC;这些值通常是统计值，分布式场景下应同时在 OMM 查看各分片实际容量。
1SELECT table_schema,2 ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb3FROM information_schema.tables4GROUP BY table_schema5ORDER BY size_mb DESC;1SELECT table_schema, table_name, partition_name,2 partition_method, partition_expression, table_rows3FROM information_schema.partitions4WHERE table_schema = 'appdb'5 AND table_name = 'orders';1INSERT INTO appdb.orders2 (order_id, customer_id, order_time, amount, status)3VALUES4 (10001, 2001, NOW(), 99.00, 'PAID');1INSERT INTO appdb.orders2 (order_id, customer_id, order_time, amount, status)3VALUES4 (10002, 2002, NOW(), 199.00, 'NEW'),5 (10003, 2003, NOW(), 299.00, 'NEW');1UPDATE appdb.orders2SET status = 'PAID'3WHERE order_id = 10002;1DELETE FROM appdb.orders2WHERE order_id = 10003;1START TRANSACTION;1COMMIT;1ROLLBACK;1SAVEPOINT before_update;1ROLLBACK TO SAVEPOINT before_update;1SELECT @@SESSION.transaction_isolation;部分兼容版本可能使用 @@tx_isolation。
1SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;1SELECT @@autocommit;1SET SESSION autocommit = 0;1SELECT *2FROM appdb.orders3WHERE order_id = 100014FOR UPDATE;1SELECT order_id, COUNT(*) AS cnt2FROM appdb.orders3GROUP BY order_id4HAVING COUNT(*) > 1;1SHOW FULL PROCESSLIST;1SELECT id, user, host, db, command, time, state, info2FROM information_schema.processlist3ORDER BY time DESC;1KILL CONNECTION 12345;执行前确认会话所属应用及事务影响。
1KILL QUERY 12345;1EXPLAIN2SELECT *3FROM appdb.orders4WHERE customer_id = 2001;1EXPLAIN FORMAT=JSON2SELECT *3FROM appdb.orders4WHERE customer_id = 2001;是否支持 JSON 格式取决于版本和兼容模式。
1ANALYZE TABLE appdb.orders;1CHECK TABLE appdb.orders;1SHOW GLOBAL STATUS;1SHOW GLOBAL STATUS2WHERE Variable_name IN3('Threads_connected', 'Threads_running', 'Connections', 'Aborted_connects');1SHOW GLOBAL STATUS LIKE 'Com_select';1SHOW VARIABLES LIKE 'slow_query_log';实际慢 SQL 建议从 GoldenDB Insight 或 OMM 查询，以获得跨节点、跨分片的完整链路。
1SELECT id, user, host, db, time, state, info2FROM information_schema.processlist3WHERE command <> 'Sleep'4 AND time >= 605ORDER BY time DESC;1SELECT user, host, COUNT(*) AS sessions2FROM information_schema.processlist3WHERE command = 'Sleep'4GROUP BY user, host5ORDER BY sessions DESC;1SHOW VARIABLES2WHERE Variable_name IN3('connect_timeout', 'wait_timeout', 'interactive_timeout',4 'net_read_timeout', 'net_write_timeout');1SELECT user, host2FROM mysql.user3ORDER BY user, host;系统权限表的可见性取决于账号和版本。
1CREATE USER 'appuser'@'%'2IDENTIFIED BY 'Replace_With_Strong_Password';1ALTER USER 'appuser'@'%'2IDENTIFIED BY 'Replace_With_New_Strong_Password';1SHOW GRANTS FOR 'appuser'@'%';1GRANT SELECT2ON appdb.*3TO 'appuser'@'%';1GRANT SELECT, INSERT, UPDATE, DELETE2ON appdb.*3TO 'appuser'@'%';1REVOKE DELETE2ON appdb.*3FROM 'appuser'@'%';1FLUSH PRIVILEGES;通过标准 DDL 管理用户时通常会自动生效；仅在直接维护权限表等特定场景使用。
1ALTER USER 'appuser'@'%' ACCOUNT LOCK;该语法是否可用取决于 GoldenDB 版本。
1DROP USER 'appuser'@'%';1mysqldump -h 192.168.1.10 -P 3306 -u dba -p \2 --no-data appdb > appdb_ddl.sql仅适合兼容的逻辑导出场景；生产集群的统一备份应优先使用 GoldenDB 官方备份工具或 OMM。
1mysqldump -h 192.168.1.10 -P 3306 -u dba -p \2 --single-transaction appdb small_table > small_table.sql1mysql -h 192.168.1.10 -P 3306 -u dba -p appdb \2 < small_table.sql进入 OMM → 备份恢复，选择集群、备份类型、存储位置和保留周期后创建任务。
GoldenDB 公开资料确认支持热备份、库表级备份和时间点恢复；具体菜单及字段以版本手册为准。
进入 OMM → 备份恢复 → 任务列表，检查任务状态、开始时间、结束时间、备份集大小和失败原因。
选择目标备份集执行校验，重点确认备份介质可访问、元数据完整、各分片备份齐全。
通过 OMM → 备份恢复 → 恢复 选择备份集或时间点，将数据恢复到隔离环境并校验业务数据。
恢复位置、覆盖范围和回切方案必须提前确认。
在 OMM 或对应版本官方备份工具中选择数据库、表和目标位置执行恢复。
不要照搬其他版本的 dbtool 参数；其命令行参数应从当前版本产品手册获取。
在 OMM 查看最近成功全量备份、增量备份及日志归档连续性，确认实际 RPO 满足要求。
1df -h若备份使用对象存储或专用备份平台，还应在对应平台检查配额、生命周期和访问状态。
进入 OMM → 集群管理 → 集群拓扑，确认计算、数据、管理等节点角色及运行状态。
进入节点监控页面，检查节点在线状态、心跳、CPU、内存、磁盘、网络和进程告警。
查看各数据节点的分片数量、容量和副本分布，识别热点节点、分布倾斜及异常副本。
查看副本状态、复制延迟和一致性告警；修复动作应按当前版本官方故障处理流程执行。
核对主备状态、读流量分配、备节点延迟和路由策略，避免将强一致查询错误路由到延迟副本。
在 GoldenDB Insight → SQL 分析 中按耗时、扫描行数、执行次数和资源消耗排序，定位高负载 SQL。
查看长事务、阻塞事务、分布式事务状态和失败原因，重点关注长期未提交事务及异常 XA 事务。
在 OMM 告警中心按严重级别、对象和时间筛选，确认每条活动告警已有负责人和处置记录。
在 OMM 容量监控中检查数据量、日志量、备份量和磁盘增长趋势，按扩容周期预留安全空间。
每日按以下顺序检查：
1集群与节点状态2→ 分片及副本健康3→ 复制延迟与读写路由4→ 活动告警5→ 长事务与慢 SQL6→ CPU、内存、磁盘、网络7→ 备份任务与可恢复点8→ 容量增长和扩容余量GoldenDB 运维的重点不只是 MySQL 兼容 SQL，还包括接入层路由、分片、副本、分布式事务和统一备份恢复。日常查询可通过 SQL 完成，集群级操作则应以 OMM、Insight、Tool Suite 和当前版本官方手册为准。
对于公开资料未给出完整语法的扩缩容、主备切换、分片迁移和内部修复命令，本文刻意没有编造参数。此类高风险操作应由经过授权的管理员按照产品手册执行。