The ksql Meta-Commands Every MySQL DBA Needs on Day One
These ksql commands don't need semicolons, but you can't live without them for daily database checks
MySQL users switching to KingbaseES often find that their first problem after connecting to the database isn't SQL syntax — it's things like: what databases exist, which database am I currently in, which schema does a table belong to, and what permissions does this user have.
In MySQL, handling these questions involves a fixed set of actions: show databases to list databases, use db_name to switch databases, show tables to list tables, describe table to view the structure, and then another show index from table to see the indexes. In ksql, a different set of tools accomplishes the same tasks — meta-commands. These commands start with a backslash, don't require a semicolon, and are processed by the ksql client itself without being sent to the database for execution.
This article verifies the following meta-commands in a KingbaseES V009R001C010 environment: \l, \c, \dn, \dt, \d, \du, comparing each one with its MySQL counterpart.
Meta-commands and SQL are not the same thing
There are two types of commands in ksql.
The first type is SQL, sent to the database server for execution and ending with a semicolon:
select current_database(), current_user, current_schema();
The second type is meta-commands, starting with a backslash \, processed locally by the ksql client, and not requiring a semicolon:
\l
\c app_db
\dt
The way to tell them apart is straightforward: check if the command starts with \. Meta-commands control client behavior or query database metadata; they are not equivalent to executing an SQL statement. To see the full list of meta-commands, run \? in ksql. This article doesn't cover the complete list, only the ones used most often daily.
\l lists all databases
In MySQL, you use:
show databases;
In ksql, the equivalent is:
\l
After execution:
The output includes app_db, test, template0, template1, with each database followed by several columns of extra information: Owner, Encoding, Collate, Ctype, ICU Locale, ICU Rules, Access privileges.
Compared to show databases, ksql provides more than just extra fields. From this output, you can directly see that the owner of app_db is app_user, and you don't need to look elsewhere for the encoding and collation rules. show databases only gives database names; to see the owner and encoding, you'd have to query system tables separately.
template0 and template1 are template databases that come with system initialization. You won't use them for daily experiments, but they shouldn't be modified.
\c switches databases, and the prompt changes accordingly
Switching databases in MySQL:
use app_db;
In ksql, the equivalent is:
\c app_db
To specify a user at the same time:
\c app_db app_user
After execution:
After executing \c app_db, the terminal returns:
You are now connected to database "app_db" as user "app_user".
The prompt changes from test=# to app_db=>, with the database name updating in real time.
There's a fundamental difference here compared to MySQL's use. use db only switches the current database without disconnecting the original connection. \c re-establishes a connection — switching the target database or user both go through the full connection verification process.
The symbol at the end of the prompt also has meaning: # appears under a superuser connection, > is for a regular user. This can't be used as a permission check, but it quickly tells you what type of account you're currently using.
\dn lists schemas in the current database
MySQL doesn't have a schema layer (MySQL's schema is equivalent to database), so \dn is a new command for MySQL users:
\dn
After execution:
The current app_db has two schemas: public (owner is system) and app_schema (owner is app_user).
KingbaseES's hierarchy is: one instance contains multiple databases, one database contains multiple schemas, one schema contains multiple tables. MySQL's database directly contains tables, without a schema layer in between.
\dn lists the schema list, which is a prerequisite for using \dt: without knowing the target schema name, \dt can't be specified correctly.
\dt lists tables, with and without specifying a schema
Listing tables in MySQL:
show tables;
In ksql, the equivalent is:
\dt
But \dt's behavior is affected by search_path. After connecting with app_user, search_path defaults to "$user", public, and current_schema() returns public, not app_schema.
First, run \dt without parameters, then specify a schema:
\dt
\dt app_schema.*
Compare the results:
Without a schema prefix, \dt only lists tables found in schemas within the current search_path. app_schema isn't in the search_path, so those tables don't appear. After adding app_schema.*, the tables under app_schema appear in full.
MySQL's show tables only shows tables in the current database, with no schema concept to handle. ksql adds an extra layer here: without a schema, the results are controlled by search_path. To see everything, either add a prefix or modify search_path.
\dt *.* can list tables under all schemas, but when there are many schemas, the output can be very long. Specifying a schema is clearer for daily use.
\d views table structure, with more than what describe offers
Viewing table structure in MySQL takes two steps:
describe t_order_demo;
show index from t_order_demo;
In ksql, it's one command:
\d app_schema.t_order_demo
After execution:
The output has three parts.
The column list includes column names, types, whether nulls are allowed, and default values. It's similar to what describe shows, but it doesn't stop there.
The Indexes section lists all indexes on this table: the primary key index, unique constraint index, idx_order_no, idx_status. In MySQL, viewing indexes requires a separate show index from command. ksql's \d places indexes directly below the column list, eliminating the need for a second command.
The id field of type bigserial also includes a sequence reference — the corresponding sequence name appears in the output. In MySQL, auto_increment is a table attribute; here, it becomes an independent sequence object, which can be surprising the first time you see it.
If the table has foreign key constraints or check constraints, they also appear in the \d output. Columns, indexes, and constraints are all viewed at once, with no need to run a second command.
\du checks users and role attributes
Checking users in MySQL:
select user, host from mysql.user;
In ksql, the equivalent is:
\du
After execution:
The output has two rows: app_user and system. In the Attributes column, system has Superuser, Create role, Create DB, Replication, Bypass RLS, while app_user's column is empty.
An empty Attributes field means app_user has no administrative-level permissions, directly matching the nosuperuser nocreatedb nocreaterole specified when it was created.
Compared to MySQL's mysql.user table, \du doesn't require assembling query conditions, and the Attributes column shows at a glance what special permissions a user has. The superuser status of system also doesn't need to be confirmed elsewhere.
After adjusting search_path, \dt's results change
Earlier, when \dt was used without a prefix, the tables under app_schema didn't appear. Adding app_schema to search_path changes the result:
set search_path to app_schema, public;
Then run:
\dt
After execution:
set search_path executes successfully, and the \dt output now includes tables under app_schema.
search_path controls the order in which objects are found when no schema prefix is used, and \dt is also controlled by this. In SQL, table lookup follows the search_path order for resolution; object resolution in meta-commands follows the same rule. This was already seen in the schema section and is confirmed again here.
set search_path only takes effect in the current session. After disconnecting and reconnecting, it returns to the default value. Persistent settings require operations at the user level or database level, which won't be expanded on here.
Also: There are two recent events you can choose to participate in
- Recommend Opportunities, Win Rewards — Kingbase Community "Companion Program" Launches (https://bbs.kingbase.com.cn/forumDetail?articleId=1d09d598f414ab764eda4907e8f54758)
- 2026 Kingbase Database Intelligent O&M Tool Development Competition (https://bbs.kingbase.com.cn/forumDetail?articleId=2394013b19f3ef84a43edb994692b88e)(https://bbs.kingbase.com.cn/forumDetail?articleId=6152608d769b472397ccfbd29879c0bd)
Quick Reference Table
| MySQL Action | ksql Meta-command |
|---|---|
show databases |
\l |
use db_name |
\c db_name |
show tables |
\dt (affected by search_path) |
show tables (specify schema) |
\dt schema.* |
describe table_name |
\d table_name (includes indexes and constraints) |
show index from table |
Included in \d table_name |
select user from ... |
\du |
| (No equivalent) | \dn lists schemas |
Top 1 from juejin.cn, machine-translated. The original thread is authoritative.
Isn't this a security risk?