KingbaseES数据库：ksql 命令行用户与权限全攻略，从创建到删除

KingbaseES数据库：ksql 命令行用户与权限全攻略，从创建到删除

搞定数据库、表、索引这些核心对象后，“用户与权限控制”就成了KingbaseES数据安全的“守护神”。通过细致的用户操作和权限分配，能轻松避开未授权访问、误操作这类坑——总不能让普通用户随手删了核心表吧？

这篇就跟大家唠唠“ksql命令行操作用户与权限”那点事儿，从“创建用户→查看用户→修改用户→授权/回收权限→删除用户”，一整套流程全给你安排明白。还会结合真实业务场景拆解题步骤，每个环节都附上语法、例子，再提提常见错误的避雷指南，就算是新手，也能把安全控制的重点拿捏住！

一、前置准备：明确“谁来操作”与“操作基础”

用户与权限操作可不是小事，属于“高危动作”，得先确保操作环境没问题（结合之前讲的内容，别到时候因为权限不够或环境不对，操作半天白忙活）。

1.1 用管理员账号连接数据库

管理员用户（比如默认的system）才有创建、修改、删除其他用户的权限，普通用户可没这本事。所以第一步，得用ksql以管理员身份连上本地数据库。

# 连接默认数据库kingbase，用户为system
ksql -d kingbase -U system

连接成功后，提示符会变成kingbase=#。这里有个小技巧：管理员的提示符是#，普通用户是>，看提示符就能秒懂当前权限等级，是不是很方便？

1.2 确认操作依赖的对象（衔接前文）

后面举权限例子时，得用到之前创建的这些对象，先确认它们都在（要是不在，就得回头看之前的内容重新创建，不然例子执行会报错）：

• 数据库：kingbase（默认数据库）、test（之前建的测试库）；
• 模式：test_schema（之前建的模式）；
• 表：test_schema.sys_user（之前建的用户表）。

怎么确认呢？用l查数据库、dn查模式、dt test_schema.*查表就行，一步到位。

二、核心概念：用户与权限的“层级关系”

新手学KingbaseES权限，得先搞懂它的“层级特性”——权限按“数据库→模式→表”从高到低分等级，只有拿到上层权限，才能操作下层对象。打个比方，要是连数据库的连接权限都没有，想操作库里的表？门儿都没有！

KingbaseES的权限层级是默认自带的，后面所有权限操作都得围着这三个层级转，这样才能做到“最小化授权”——只给用户刚好够用的权限，可别一股脑全给，免得惹麻烦。

三、创建用户：基础用户管理第一步

创建用户是权限管理的起点，得把用户名、密码还有一些基本属性（比如默认数据库、密码有效期）都设好。下面就讲讲CREATE USER的关键语法，再结合安全好习惯给大家举个例子。

3.1 基础语法

CREATE USER 用户名 WITH PASSWORD '密码' [选项];

这些“选项”新手也得弄明白，不然容易踩坑：

• PASSWORD '密码'：用户登录密码，建议混着大小写、数字、特殊字符来，别用“123456”这种一猜就中的弱密码；
• DEFAULT DATABASE 数据库名：用户登录时默认连接的数据库，比如kingbase；
• DEFAULT SCHEMA：用户默认用的模式，比如test_schema；
• CREATEDB：允许用户创建数据库（之前提过，这权限只有管理员能给）；
• INHERIT：用户会自动继承所属角色的权限，这个默认是开着的，不用手动设。

3.2 实操示例：创建普通用户

示例：创建基础用户test（就用来访问数据，没建库权限）

CREATE USER test WITH PASSWORD '123456' 

执行完要是提示CREATE ROLE，就说明成了。你可能会问，不是创建用户吗？怎么显示“创建角色”？其实在KingbaseES里，“用户”本质就是个特殊角色，所以别慌，这是正常的。

3.3 注意事项（安全必看）

1. 密码复杂度：生产环境里，密码至少8位，大小写、数字、特殊字符都得有，可别偷懒用“123456”；
2. 避免重复创建：要是用户名已经存在，再执行CREATE USER就会报错“role already exists”，这时候要么先删了旧用户，要么用ALTER USER去修改。

四、查看用户：了解用户权限与属性

用户创建好后，得用ksql命令看看它的详细信息，比如权限、默认属性、所属角色这些。推荐用du系列命令，直观又好用，一看就懂。

4.1 查看所有用户（du命令）

执行du，当前数据库里所有用户的核心信息都会列出来，想快速了解用户列表，用它准没错：

du

4.2 查看单个用户详情（du 用户名）

要是想具体看某个用户（比如test）的权限，就执行du 用户名：

du test

4.3 查看用户的权限明细（dp命令）

要是想更细致地看用户对表、模式这类对象的权限，dp命令就派上用场了：

• 查看表权限：dp 表名（比如看sys_user表的权限）；

dp test_schema.sys_user

五、修改用户：适配用户属性变更

业务需求一变，用户属性也得跟着调，比如重置密码、加个建库权限，或者把建库权限收回来。ALTER USER就是干这个的，下面讲讲常见操作。

5.1 修改用户密码（最常用操作）

用户忘密码了，或者到了该换密码的时候，管理员就可以这么操作（以test为例）：

-- 语法：ALTER USER 用户名 WITH PASSWORD '新密码';
ALTER USER test WITH PASSWORD 'User1@New2024';

改完怎么验证？让用户用ksql -d kingbase -U user1命令重新登录，输入新密码能登上，就说明改成功了。

5.2 授予用户属性（如建库权限）

要是想给test加个创建数据库的权限（之前没给过），就这么来：

-- 语法：ALTER USER 用户名 权限属性;
ALTER USER test CREATEDB;

验证也简单，执行du test，在Attributes栏里看到“创建DB”，就说明权限加上了。

5.3 撤销用户属性（如收回建库权限）

要是test用不上建库权限了，得及时收回来，避免权限浪费：

-- 语法：ALTER USER 用户名 NO 权限属性;
ALTER USER test NOCREATEDB;

再执行du test，Attributes里的“Create DB”没了，就说明收成功了。

5.4 修改用户默认属性（如默认数据库）

想把user1的默认数据库从kingbase改成test（得先确保test数据库存在），就执行：

ALTER USER test SET DEFAULT DATABASE test;

等test下次登录，直接用ksql -U user1命令，系统会自动连test数据库，不用再手动加-d test参数，省事儿多了。

六、权限控制：授予与回收（核心环节）

权限控制可是用户操作的核心，得按“数据库→模式→表”的层级来授权限、收权限，保证用户只敢动自己业务范围内的对象。下面就详细说说GRANT（授予）和REVOKE（回收）在不同场景下怎么用。

6.1 授予权限（GRANT命令）

场景1：授予数据库连接权限（用户得先能连库，才能操作里面的对象）

想让test连kingbase数据库，就这么授权限：

-- 语法：GRANT 权限类型 ON DATABASE 数据库名 TO 用户名;
GRANT CONNECT ON DATABASE kingbase TO test;

要是没这个权限，test连kingbase数据库时会报错“permission denied to connect to database kingbase”，所以这步可不能少。

场景2：授予模式访问权限（用户得能访问模式，才能操作模式下的表）

给test授访问test_schema模式的权限：

-- 语法：GRANT 权限类型 ON SCHEMA 模式名 TO 用户名;
GRANT USAGE ON SCHEMA test_schema TO test;

USAGE权限是访问模式的基础，没这权限，test连test_schema下的表都看不着，更别说操作了。

场景3：授予表操作权限（用户业务核心权限，比如查询、插入）

给test授test_schema.sys_user表的SELECT（查询）和INSERT（插入）权限：

-- 语法：GRANT 权限类型 ON 表名 TO 用户名;
GRANT SELECT, INSERT ON test_schema.sys_user TO test;

• 进阶：要是想给所有权限（这可得谨慎！生产环境里别这么干）：

GRANT ALL PRIVILEGES ON test_schema.sys_user TO test;

想验证的话，执行dp test_schema.sys_user，就能看到test有哪些权限了。

6.2 回收权限（REVOKE命令）

要是用户用不上某个权限了（比如test不用再插入数据），得赶紧收回来，别留着有数据风险。

场景：回收test对sys_user表的INSERT权限

-- 语法：REVOKE 权限类型 ON 表名 FROM 用户名;
REVOKE INSERT ON test_schema.sys_user FROM test;

执行dp test_schema.sys_user，要是test只剩SELECT权限，就说明收成功了。这里要注意，只有管理员能回收权限，而且只能回收之前授出去的权限，用户默认有的权限可收不了。

七、删除用户：高危操作，谨慎执行

把用户删了，他的相关权限也会跟着没，但他创建的表、视图这些对象还在。执行这步之前，一定要确认这用户跟核心业务没关系了，不然删错了可就麻烦了。具体步骤如下：

7.1 基础语法（加IF EXISTS避免报错）

DROP USER IF EXISTS 用户名;

IF EXISTS这个参数很实用，要是用户不存在，只会提示“NOTICE: role "用户名" does not exist, skipping”，不会报错，不影响后面的操作。

7.2 特殊场景：用户有创建的对象（需CASCADE）

要是test已经创建了表（比如test_schema.user2_table），直接删会报错：“role 'test' 无法被删除，因为存在对象依赖于此角色”。这时候就得加CASCADE参数做级联删除，解决依赖问题（不过这只会删跟用户相关的权限，他创建的表、视图这些还得自己手动删）。

-- 语法：DROP USER IF EXISTS 用户名 CASCADE;
DROP USER IF EXISTS test CASCADE;

这里必须提醒一句：CASCADE只是处理“用户有依赖对象”的删除问题，可不会删用户创建的表、视图。要是想删这些，还得自己执行DROP操作（比如：DROP TABLE test_schema.user2_table;）。

7.3 删除前的确认步骤（必做）

1. 确认用户没有活跃会话：执行SELECT pid, usename FROM pg_stat_activity WHERE usename = 'user1';，要是有结果，先执行SELECT pg_terminate_backend(pid);终止会话；
2. 确认用户没有核心权限：执行du user1，看看用户有没有Superuser这类关键权限；
3. 确认用户没有业务对象：执行SELECT tablename FROM pg_tables WHERE tableowner = 'user1';，确认用户没创建过表。

八、常见问题排查：新手常踩的权限坑

问题1：用户登录报错“连接数据库的权限被拒绝”

报错信息：

ERROR:  permission denied to connect to database "kingbase"

原因：用户没有这个数据库的CONNECT权限（比如user1没被授予连kingbase的权限）。
解决方案：管理员给授CONNECT权限：

GRANT CONNECT ON DATABASE kingbase TO user1;

问题2：用户查询表报错“对模式的权限被拒绝”

报错信息：

ERROR:  permission denied for schema test_schema

原因：用户没有这个模式的USAGE权限，没法访问模式下的表。
解决方案：给授模式访问权限：

GRANT USAGE ON SCHEMA test_schema TO user1;

问题3：删除用户报错“存在依赖它的对象”

报错信息：

ERROR:  role "user1" cannot be dropped because some objects depend on it

原因：用户创建过表、视图这类对象，或者被授予了其他对象的权限。
解决方案：加CASCADE做级联删除，处理依赖：

DROP USER IF EXISTS user1 CASCADE;

• 之后还得手动删用户创建的对象（比如DROP TABLE test_schema.user1_table;）。

九、总结：用户权限管理的核心原则

这篇把用户“创建→查看→修改→权限→删除”的全流程都讲透了，核心原则就这几条，记牢了准没错：

1. 最小权限原则：只给用户必要的权限，比如普通用户有表的SELECT权限就够了，别给DROP权限，免得闯祸；
2. 权限层级清晰：得按“数据库→模式→表”的顺序逐层授权限，可别越级。总不能连模式权限都没有，就直接给表权限吧？
3. 定期审计：要定期检查用户权限，用du和dp命令看看，多余的权限及时收回来，别让权限泄露了；
4. 高危操作谨慎：删用户前，一定要确认会话、对象、权限都没问题，别误删了影响业务。

掌握了用户与权限操作，你就有了KingbaseES数据库安全控制的“钥匙”。下一篇咱们聊聊“事务操作”，看看怎么保证多操作时数据的一致性——就像转账时，“扣款”和“入账”得要么一起成，要么一起不成，可不能出岔子！