KingbaseES数据库：ksql 命令行用户与权限全攻略，从创建到删除
本文聚焦 KingbaseES 数据库的 ksql 命令行用户与权限管理，先明确操作前需用管理员账号（如 system）连接数据库，并确认依赖的数据库、模式、表等对象存在。接着解析权限 “数据库→模式→表” 的层级关系，再分步讲解用户管理全流程：创建用户时需设置用户名、密码及属性，可通过 \du 命令查看用户信息，用 ALTER USER 修改密码、权限属性及默认配置，按层级用 GRANT 授予、REVOKE 回收权限，删除用户需谨慎，存在依赖对象时需加 CASCADE 参数。还列举了登录、查表、删用户的常见报错及解决办法，强调最小权限、层级清晰等核心原则，助力新手掌握数据安全控制要点。
搞定数据库、表、索引这些核心对象后，“用户与权限控制”就成了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 注意事项（安全必看）
- 密码复杂度：生产环境里，密码至少8位，大小写、数字、特殊字符都得有，可别偷懒用“123456”；
- 避免重复创建：要是用户名已经存在，再执行
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 删除前的确认步骤（必做）
- 确认用户没有活跃会话：执行
SELECT pid, usename FROM pg_stat_activity WHERE usename = 'user1';，要是有结果，先执行SELECT pg_terminate_backend(pid);终止会话； - 确认用户没有核心权限：执行
\du user1，看看用户有没有Superuser这类关键权限； - 确认用户没有业务对象：执行
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;）。
九、总结：用户权限管理的核心原则
这篇把用户“创建→查看→修改→权限→删除”的全流程都讲透了，核心原则就这几条，记牢了准没错：
- 最小权限原则：只给用户必要的权限，比如普通用户有表的
SELECT权限就够了，别给DROP权限，免得闯祸； - 权限层级清晰：得按“数据库→模式→表”的顺序逐层授权限，可别越级。总不能连模式权限都没有，就直接给表权限吧？
- 定期审计：要定期检查用户权限，用
\du和\dp命令看看，多余的权限及时收回来，别让权限泄露了； - 高危操作谨慎：删用户前，一定要确认会话、对象、权限都没问题，别误删了影响业务。
掌握了用户与权限操作，你就有了KingbaseES数据库安全控制的“钥匙”。下一篇咱们聊聊“事务操作”，看看怎么保证多操作时数据的一致性——就像转账时，“扣款”和“入账”得要么一起成，要么一起不成，可不能出岔子！
