完成数据库安装后，不要急于创建业务表，也不要立刻钻研复杂的语法——最优先的任务是，先用客户端连接数据库，确保通信链路稳定可靠。

长期使用 MySQL 会形成一套惯性操作：服务启动后，输入 mysql -h -P -u -p 进入交互界面，再顺手执行 select version() 验证。这套流程看似简单，却解决了最基础且最关键的问题：当前连接的是哪台主机、哪个端口、哪个用户、哪个数据库。

切换到 KingbaseES 后，入口变为 ksql。命令本身并不复杂，但参数写法不能直接套用 MySQL 的习惯。尤其是数据库名——如果未显式指定，很容易遇到一个看似连接失败、实则默认库不匹配的错误。

先确认当前使用的 ksql 版本

安装目录中不仅包含数据库服务端程序，也自带客户端工具。开始连接前，最好先确认当前 shell 中找到的 ksql 具体来自哪个路径。

which ksqlksql --versionksql --help | head -n 40

在当前环境中，ksql 位于安装目录下的 Server/bin：

/acowbo/kingbase/install/KESRealPro/V009R001C010/Server/bin/ksql

版本信息显示：

ksql (KingbaseES) V009R001C010

这一步看似简单，但后续排查问题时非常实用。如果机器上安装了多个版本，或者 PATH 中混入了其他客户端工具，提前确认命令来源可以节省大量绕弯路的时间。

ksql --help 中也能看到参数习惯：数据库名用 -d，用户名用 -U，端口用 -p。这些参数的大小写与 MySQL 不同，需要特别留意。

MySQL:mysql -h 127.0.0.1 -P 3306 -u root -pKingbaseES:ksql -h 127.0.0.1 -p 54321 -U system -d test

对 MySQL 用户来说，最容易写错的是端口和用户名：MySQL 端口是大写 -P，用户是小写 -u；而 ksql 端口是小写 -p，用户是大写 -U。这个细微差异在刚切换时几乎一定会遇到。

还有一个细节：ksql 的帮助中用法格式为 ksql [OPTION]... [DBNAME [USERNAME]]。也就是说，数据库名和用户名除了用参数指定，也可以直接放在命令末尾。不过，在实际编写文章或脚本时，使用 -U、-d 的方式更直观、更清晰。

两种写法都能表达连接目标：

ksql -h 127.0.0.1 -p 54321 -U system -d testksql -h 127.0.0.1 -p 54321 test system

前一种更适合放在文章和脚本中。参数名一目了然，后续排查连接问题时，无需猜测最后两个位置参数的含义。

缺少数据库名时，错误信息容易误导

先看一条不完整的连接命令：

ksql -h 127.0.0.1 -p 54321 -U system

输入密码后，返回的是：

FATAL: database "system" does not exist

这个错误容易让人误判。它并不是在说“服务未启动”或“密码错误”——密码已经通过校验，服务端也有响应，真正的问题是未指定目标数据库。

ksql 在没有带 -d 时，会尝试连接一个与用户名同名的数据库。当前用户是 system，它就查找名为 system 的数据库。实例中不存在该库，于是报错 database "system" does not exist。

这一点与 MySQL 的使用习惯差异很大。MySQL 中通常先用管理员用户登录，再通过 use 库名 切换；而在 KingbaseES 中，最好一开始就明确指定目标数据库。

这类错误也提醒我们：连接数据库时不要只盯着“账号密码对不对”。主机、端口、用户、数据库名这四个参数共同协作。服务能响应、密码能通过，并不代表目标数据库一定存在。以后遇到 could not connect to server、password authentication failed、database does not exist 等错误时，要分开判断，不能一概视为连接失败。

加上 -d 参数，先连接 test 库

补上数据库名后，连接命令变为：

ksql -h 127.0.0.1 -p 54321 -U system -d test

这次可以正常进入交互界面，提示符变为：

test=#

这条命令中包含四个主要参数：

-h 127.0.0.1   连接本机数据库服务-p 54321       连接端口-U system      登录用户-d test        目标数据库

这里的 test 是初始化后可连接的默认库。实际环境中可以替换为自己的业务库或实验库，关键是不要让客户端去猜测默认库。

提示符也可以顺便观察。test=# 中的 test 是当前数据库，后面的 # 与当前高权限用户有关。后续换成普通用户连接 app_db 时，提示符会变为 app_db=>。它虽然不能作为权限检查工具，但能快速判断当前连接的是哪个库、使用的是什么级别的用户。

连接成功后，先确认当前位置

进入交互界面后，先查询当前数据库、当前用户和版本：

select current_database(), current_user;select version();

当前返回结果中，数据库是 test，用户是 system，版本是 KingbaseES V009R001C010。

MySQL 中常用 select database();、select user(); 查看当前位置。KingbaseES 中对应的命令是：

select current_database(), current_user;

命令不同，但作用类似。后续创建用户、创建数据库、建表时，先确认当前库和当前用户，可以避免很多低级错误。

再测试一个最小查询：

select 1;

然后用 conninfo 查看当前连接信息：

conninfo

最后退出：

q

这里顺便介绍了 ksql 中的另一类命令：以反斜杠开头的是客户端元命令，而非 SQL。例如 conninfo 查看连接信息，q 退出客户端。元命令可以后续单独展开，这里只需知道它不会发送给数据库执行即可。

select 1; 这类 SQL 会被发送到数据库执行；而 conninfo 和 q 由 ksql 客户端自己处理。这一点与 MySQL 客户端中的部分命令类似，比如 status、source、q 等操作并非完整的 SQL。先分清这个边界，后续看到 l、d、dt 时就不会困惑：为什么这些命令不需要分号，为什么它们不是标准 SQL。

利用环境变量简化连接

熟悉完整参数后，可以使用环境变量减少重复输入。

export KINGBASE_HOST=127.0.0.1export KINGBASE_PORT=54321export KINGBASE_USER=systemexport KINGBASE_DATABASE=test

再执行：

ksql

客户端会自动读取这些环境变量，直接连接到对应数据库。

环境变量适用于固定连接目标。例如，如果这台测试机一直连接 127.0.0.1:54321 的 test 库，就可以少敲一串参数。

临时测试时，先放在当前终端即可，不必急于写入 .bashrc。要确认当前 shell 中保留了哪些值，可以直接查看：

echo $KINGBASE_HOSTecho $KINGBASE_PORTecho $KINGBASE_USERecho $KINGBASE_DATABASE

在切换用户、库或服务器之前，最好先清除旧值：

unset KINGBASE_HOST KINGBASE_PORT KINGBASE_USER KINGBASE_DATABASE

这样再执行 ksql 时，就会回到手动传参的状态，不会带着上一次的连接目标。

避免长期使用 system 用户进行实验

前面的连接都使用了 system 用户。安装初始化阶段使用它没有问题，但日常编写 SQL、测试表结构、进行小实验时，最好不要一直使用管理员用户。

这里创建一个普通用户：

create user app_user with password '<实验密码>' nosuperuser nocreatedb nocreaterole;

执行成功后返回：

CREATE ROLE

再用 du 查看角色列表，可以看到 app_user 已经存在。

这里有一个细节：命令写的是 create user，返回却是 CREATE ROLE。这不是异常。官方文档中说明，CREATE USER 是 CREATE ROLE 的别名，区别在于 CREATE USER 默认带有登录属性。也就是说，KingbaseES 中的用户和角色体系是统一理解的。

这里不展开完整的权限模型，只需先做一个最小隔离：管理员用户负责创建资源，普通用户负责实验操作。

nosuperuser nocreatedb nocreaterole 这几个选项无需死记硬背，先看字面意思即可：不是超级用户，不能创建数据库，不能创建角色。也就是说，app_user 只是一个普通登录用户。这样后续用它建表、插入数据时，更接近日常应用账号的状态，而不是一直用管理员权限掩盖问题。

创建用户时的密码仅用于本地实验，公开内容中不要放置真实密码。示例中可以写成 <实验密码>，实际操作时按自己的密码策略设置。命令输出中如果出现密码，也应提前打码。

为普通用户创建专属数据库

用户创建完成后，再创建一个数据库，并将 owner 指向该用户：

create database app_db owner app_user;

执行成功后，用 l 查看数据库列表。app_db 出现在列表中，owner 是 app_user。

这里需要分清两个概念：用户和数据库不是一回事。app_user 是登录身份，app_db 是数据库。将 app_db 的 owner 指定为 app_user，再用这个用户连接该库，就不必一直依赖 system。

官方 CREATE DATABASE 文档中也有对应语法，OWNER 可以指定新数据库的所有者。创建数据库本身需要超级用户或 CREATEDB 权限，这也是这里继续使用 system 执行创建的原因。

与 MySQL 对比时，这里也容易产生错觉。MySQL 中经常将“一个库 + 一个用户 + 一组授权”放在一起理解，业务上也会说“给某个用户建一个库”。KingbaseES 中仍然可以这样组织实验环境，但概念上要分开：用户是用户，数据库是数据库，owner 是数据库的所有者，后续还会遇到 schema 和对象权限。当前这一步只将用户和数据库绑定，不一次性讲完权限体系。

用普通用户重新连接测试

退出当前连接后，用普通用户连接新库：

ksql -h 127.0.0.1 -p 54321 -U app_user -d app_db

进入后先确认当前身份：

select current_database(), current_user;

返回结果为 app_db 和 app_user。这说明连接目标已从管理员用户的 test 切换到普通用户自己的数据库。

接着进行一个简单的写入验证：

create table t_ksql_conn_demo(id int, name varchar(50));insert into t_ksql_conn_demo values (1, 'hello ksql');select * from t_ksql_conn_demo;

结果能查到 hello ksql，说明该普通用户不仅能连接数据库，还能在自己的库中完成建表和写入操作。

至此，ksql 入门就已超越“连接成功”的层面。连接参数、默认数据库、当前用户、普通用户、数据库 owner 等概念已串联起来。

这个小表没有业务含义，仅用于验证连接后的写入能力。相比单纯执行 select 1，这一步更进一步：select 1 只能说明查询可执行，而建表和插入成功，才能证明该用户在当前库中确实拥有基本操作权限。后续要继续练习 SQL，也可以从这个 app_db 开始，避免在 test 库中越堆越乱。

先调整连接习惯

从 MySQL 迁移到 ksql，第一关不是 SQL 方言，而是连接习惯。

mysql 常用的是：

mysql -h 127.0.0.1 -P 3306 -u root -p

ksql 建议一开始就写完整：

ksql -h 127.0.0.1 -p 54321 -U app_user -d app_db

几个最容易踩的坑：

端口参数：MySQL 是 -P，ksql 是 -p用户参数：MySQL 是 -u，ksql 是 -U数据库名：ksql 最好显式写 -d默认行为：不写 -d 时，可能尝试连接与用户名同名的数据库管理员用户：system 用来初始化和管理，不适合所有实验都压在它身上