ksql 里这些命令不用加分号，但日常查库少不了

ksql 里这些命令不用加分号，但日常查库少不了

MySQL 用户切到 KingbaseES 以后，连进库的第一个问题通常不是 SQL 语法，而是：库有哪些、当前在哪个库、表在哪个 schema、这个用户是什么权限。

MySQL 里处理这类问题有一套固定动作：show databases 列库，use db_name 切库，show tables 列表，describe table 看结构，还要再跑一条 show index from table 才能看索引。ksql 里完成同样任务的是另一套东西------元命令。这些命令以反斜杠开头，不需要分号，ksql 客户端自己处理，不发给数据库执行。

这篇在 KingbaseES V009R001C010 环境里验证以下几个元命令：\l、\c、\dn、\dt、\d、\du，逐一和 MySQL 对应动作对照。

元命令和 SQL 不是同一种东西

ksql 里的命令分两类。

第一类是 SQL，发给数据库服务端执行，以分号结尾：

select current_database(), current_user, current_schema();

第二类是元命令，以反斜杠 \ 开头，ksql 客户端本地处理，不用分号：

\l
\c app_db
\dt

分辨方法很直接：看命令是不是 \ 开头。元命令控制的是客户端行为，或者查询数据库的元数据，不等同于执行一条 SQL 语句。想查完整的元命令列表，在 ksql 里执行 \? 即可。这篇不覆盖完整列表，只走日常用得最多的几个。

\l 列出所有数据库

MySQL 里用：

show databases;

ksql 里对应的是：

\l

执行后：

输出里包含 app_db、test、template0、template1，每个库还跟着几列额外信息：Owner、Encoding、Collate、Ctype、ICU Locale、ICU Rules、Access privileges。

和 show databases 相比，ksql 这里多出来的不只是字段数量。从这个输出能直接看出 app_db 的 owner 是 app_user，编码和排序规则也不用再查别的地方。show databases 只给库名，要看 owner 和编码还要单独查系统表。

template0 和 template1 是系统初始化时自带的模板数据库，日常实验用不到，但不应该改动。

\c 切换数据库，提示符会跟着变

MySQL 里切换数据库：

use app_db;

ksql 里对应的是：

\c app_db

同时指定用户的写法：

\c app_db app_user

执行后：

执行 \c app_db 后，终端返回：

You are now connected to database "app_db" as user "app_user".

提示符从 test=# 变成了 app_db=>，库名实时更新。

这里和 MySQL 的 use 有本质区别。use db 只是切换当前库，不断开原连接。\c 是重新建立一次连接------换目标库、换用户，都会走完整的连接校验流程。

提示符末尾的符号也有含义：# 出现在超级用户连接下，> 是普通用户。这不能作为权限检查手段，但能快速辨别当前用的是哪类账号。

\dn 列出当前数据库里的 schema

MySQL 里没有 schema 这一层（MySQL 的 schema 就等于 database），\dn 对 MySQL 用户来说是个新命令：

\dn

执行后：

当前 app_db 里有两个 schema：public（owner 是 system）和 app_schema（owner 是 app_user）。

KingbaseES 的层级关系是：一个实例包含多个数据库，一个数据库包含多个 schema，一个 schema 包含多张表。MySQL 的 database 直接包含表，中间没有 schema 这层。

\dn 列出 schema 列表，是后面使用 \dt 的前提：不知道目标 schema 的名字，\dt 就没法正确指定。

\dt 列表，带和不带 schema 的差别

MySQL 里列表：

show tables;

ksql 里对应的是：

\dt

但 \dt 的行为受 search_path 影响。用 app_user 连进来以后，search_path 默认是 "$user", public，current_schema() 返回的是 public，不是 app_schema。

先不加参数执行 \dt，再指定 schema 执行：

\dt
\dt app_schema.*

对比结果：

不加 schema 前缀时，\dt 只列出当前 search_path 里能找到的 schema 下的表。app_schema 没在 search_path 里，所以这批表看不到。加上 app_schema.* 以后，app_schema 下的表才完整出现。

MySQL 的 show tables 只显示当前库下的表，没有 schema 的概念要处理。ksql 这里多了一层：不带 schema 时，结果受 search_path 控制，想看全要么加前缀，要么改 search_path。

\dt *.* 可以列出所有 schema 下的表，但 schema 多时输出会很长，日常指定 schema 更清晰。

\d 看表结构，比 describe 多出来的部分

MySQL 里看表结构要两步：

describe t_order_demo;
show index from t_order_demo;

ksql 里一条命令：

\d app_schema.t_order_demo

执行后：

输出里有三个部分。

字段列表，包含字段名、类型、是否允许为空、默认值。和 describe 看到的内容差不多，但不止于此。

Indexes 部分，列出了这张表上的所有索引：主键索引、唯一约束索引、idx_order_no、idx_status。MySQL 里看索引要单独跑 show index from，ksql 的 \d 把索引直接跟在字段列表下面，不用第二条命令。

bigserial 类型的 id 字段还会多出序列引用------对应的 sequence 名会出现在输出里。MySQL 里 auto_increment 是表的属性，这里变成了一个独立的序列对象，第一次看到时容易意外。

如果表上有外键约束或检查约束，也会出现在 \d 的输出里。字段、索引、约束一次看完，不需要再跑第二条命令。

\du 查用户和角色属性

MySQL 里查用户：

select user, host from mysql.user;

ksql 里对应的是：

\du

执行后：

输出里有两行：app_user 和 system。Attributes 列里，system 带了 Superuser, Create role, Create DB, Replication, Bypass RLS，app_user 这一列是空的。

Attributes 为空说明 app_user 没有任何管理级权限，和当初创建时写的 nosuperuser nocreatedb nocreaterole 直接对上了。

相比 MySQL 的 mysql.user 表，\du 不需要拼查询条件，Attributes 列一眼能看出这个用户有哪些特殊权限。system 的超级用户身份也不需要再查别的地方确认。

调整 search_path 以后，\dt 的结果会变

前面 \dt 不加前缀时，app_schema 下的表没有显示出来。把 app_schema 加进 search_path，结果就不同了：

set search_path to app_schema, public;

再执行：

\dt

执行后：

set search_path 执行成功，\dt 输出里出现了 app_schema 下的表。

search_path 控制不加 schema 前缀时找对象的顺序，\dt 也受这个控制。SQL 里找表按 search_path 顺序解析，元命令里的对象解析遵循同样的规则，这在 schema 篇里已经出现过，这里再次印证。

set search_path 只在当前会话里生效，关掉连接重新连以后会回到默认值。持久化设置需要在用户级别或数据库级别操作，这里先不展开。

另：最近有两个活动大家可以选择参与一下

1、荐商机·赢好礼------金仓社区"同行者计划"开启（bbs.kingbase.com.cn/forumDetail...

2、2026金仓数据库智能运维工具开发大赛（bbs.kingbase.com.cn/forumDetail...

对照速查表

MySQL 动作	ksql 元命令
show databases	\l
use db_name	\c db_name
show tables	\dt（受 search_path 影响）
show tables（指定 schema）	\dt schema.*
describe table_name	\d table_name（含索引和约束）
show index from table	包含在 \d table_name 里
select user from ...	\du
（无对应）	\dn 列出 schema