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 對應動作對照。
ksql 裡的命令分兩類。
第一類是 SQL,送給資料庫伺服器執行,以分號結尾:
sql 代碼解讀複製代碼select current_database(), current_user, current_schema();
第二類是元命令,以反斜線 \ 開頭,ksql 用戶端本地處理,不用分號:
text 代碼解讀複製代碼\l
\c app_db
\dt
辨別方法很直接:看命令是不是以 \ 開頭。元命令控制的是用戶端行為,或者查詢資料庫的中繼資料,不等同於執行一條 SQL 語句。想查完整的元命令列表,在 ksql 裡執行 \? 即可。這篇不涵蓋完整列表,只介紹日常最常用的幾個。
MySQL 裡用:
sql 代碼解讀複製代碼show databases;
ksql 裡對應的是:
text 代碼解讀複製代碼\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 是系統初始化時自帶的範本資料庫,日常實驗用不到,但不應該改動。
MySQL 裡切換資料庫:
sql 代碼解讀複製代碼use app_db;
ksql 裡對應的是:
text 代碼解讀複製代碼\c app_db
同時指定使用者的寫法:
text 代碼解讀複製代碼\c app_db app_user
執行後:

執行 \c app_db 後,終端回傳:
text 代碼解讀複製代碼You are now connected to database "app_db" as user "app_user".
提示符從 test=# 變成了 app_db=>,資料庫名稱即時更新。
這裡和 MySQL 的 use 有本質差異。use db 只是切換目前資料庫,不會斷開原本的連線。\c 是重新建立一次連線——換目標資料庫、換使用者,都會走完整的連線驗證流程。
提示符尾端的符號也有含義:# 出現在超級使用者連線下,> 是一般使用者。這不能作為權限檢查手段,但能快速辨別目前用的是哪類帳號。
MySQL 裡沒有 schema 這一層(MySQL 的 schema 就等於 database),\dn 對 MySQL 使用者來說是個新命令:
text 代碼解讀複製代碼\dn
執行後:

目前 app_db 裡有兩個 schema:public(owner 是 system)和 app_schema(owner 是 app_user)。
KingbaseES 的層級關係是:一個執行個體包含多個資料庫,一個資料庫包含多個 schema,一個 schema 包含多張表。MySQL 的 database 直接包含表,中間沒有 schema 這層。
\dn 列出 schema 清單,是後面使用 \dt 的前提:不知道目標 schema 的名稱,\dt 就沒法正確指定。
MySQL 裡列出表:
sql 代碼解讀複製代碼show tables;
ksql 裡對應的是:
text 代碼解讀複製代碼\dt
但 \dt 的行為受 search_path 影響。用 app_user 連進來以後,search_path 預設是 "$user", public,current_schema() 回傳的是 public,不是 app_schema。
先不加參數執行 \dt,再指定 schema 執行:
text 代碼解讀複製代碼\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 更清楚。
MySQL 裡看表結構要兩步:
sql 代碼解讀複製代碼describe t_order_demo;
show index from t_order_demo;
ksql 裡一條命令:
text 代碼解讀複製代碼\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 的輸出裡。欄位、索引、約束一次看完,不需要再跑第二條命令。
MySQL 裡查使用者:
sql 代碼解讀複製代碼select user, host from mysql.user;
ksql 裡對應的是:
text 代碼解讀複製代碼\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 的超級使用者身分也不需要再查別的地方確認。
前面 \dt 不加前綴時,app_schema 下的表沒有顯示出來。把 app_schema 加進 search_path,結果就不同了:
sql 代碼解讀複製代碼set search_path to app_schema, public;
再執行:
text 代碼解讀複製代碼\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