引言
完成数据库，表，索引这些核心对象的运作之后，“用户与权限控制”就成了保障 KingbaseES 数据安全的重点所在，经由细致的用户运作和权限分配，可以规避未授权访问以及误操作之类的风险，比如普通用户就无权删除核心表。本文针对“ksql 命令行操作用户与权限”展开论述，覆盖从“创建用户 - 查看用户 - 修改用户 - 授权/回收权限 - 删除用户”这样完整的流程，并结合真实的业务场景来分解具体的执行步骤，各个阶段均给出相关的语法，例子以及防止常见错误的提示，从而保证初学者能够掌握到安全控制的主要要点。
@[toc]
一、前置准备：明确 “谁来操作” 与 “操作基础”
用户与权限运作属于“高危运作”，要保证运作环境具备如下条件（结合前面内容，防止因为权限不够或者环境有误致使运作出现故障）
1.1 1. 用管理员账号连接数据库
管理员用户（比如预设的 system）具备创建，更改，删除其他用户的相关权限，普通用户并不具有这些权限，要经由 ksql 以管理员的身份去关联本地数据库
# 连接默认数据库 kingbase，用户为 system
ksql -d kingbase -U system
连接创建之后，提示符变为 kingbase=#，其中，管理员的提示符是 #，普通用户的是 >，经由提示符能够立即识别出权限等级
1.2 2. 确认操作依赖的对象（衔接前文）
后续权限示例将基于前文创建的对象：
- 数据库：
kingbase（默认数据库）、test（前文创建的测试库）； - 模式：
test_schema（前文创建的模式）； - 表：
test_schema.sys_user（前文创建的用户表）；
确保这些对象存在（可通过\l查数据库、\dn查模式、\dt test_schema.*查表），若不存在可参考前文重新创建，避免示例执行失败。
二、核心概念：用户与权限的 “层级关系”
新手要先领会 KingbaseES 权限的“层级特性”，即权限按“数据库 → 模式 → 表”由高到低分级，只有得到上层权限才可操作下层对象（若无数据库关联权限，则无法操作库中的表）。 KingbaseES隐含的权限层级如下：
KingbaseES存在隐含的权限层级，后面的全部权限操作都会环绕这三个层级来执行，以此保证权限分配达到“最小化”效果（也就是仅仅给予用户所需的权限，防止出现过度授权的情况）。
三、创建用户：基础用户管理第一步
创建用户属于权限管理的起始部分，要给出用户名，密码以及一些基本属性，比如默认数据库，密码有效期限等，接下来会阐述 CREATE USER 的关键语法，并且依照安全方面的良好做法来给出例子
3.1 1. 基础语法
CREATE USER 用户名 WITH PASSWORD '密码' [选项];
下面这些“选项”的解释（适合初学者了解）：
PASSWORD '密码'：用户登录密码（建议包含大小写、数字、特殊字符，避免弱密码）；DEFAULT DATABASE 数据库名指的是用户登录时默认关联的数据库，比如kingbase。DEFAULT SCHEMA是指用户默认会用的模式，比如test_schema。CREATEDB：允许用户创建数据库（前文提到的建库权限，仅管理员可授予）；INHERIT：用户自动继承所属角色的权限（默认开启，无需手动指定）。
3.2 2. 实操示例：创建普通用户
示例 ：创建基础用户 test（仅用于访问数据，无建库权限）
CREATE USER test WITH PASSWORD '123456'
- 成功验证：执行后提示
CREATE ROLE（KingbaseES 中 “用户” 本质是特殊角色，故返回CREATE ROLE），表示用户创建成功。
3.3 3. 注意事项（安全必看）
- 密码复杂度：生产环境需设置强密码（如至少 8 位，含大小写、数字、特殊字符），避免
123456等弱密码； - 避免重复创建：若用户名已存在，执行
CREATE USER会报错 “role already exists”，需先删除旧用户或改用ALTER USER修改。
四、查看用户：了解用户权限与属性
创建好用户之后，要利用 ksql 命令来查看用户的详细信息，包含权限，默认属性以及所属角色等方面的内容，建议采用 \du 这一系列的命令，这属于一种最为直观的查看用户信息的方式。
4.1 1. 查看所有用户（\du 命令）
执行 \du 可列出当前数据库中所有用户的核心信息，快速了解用户列表：
\du
执行结果示例（关键信息筛选）：
4.2 2. 查看单个用户详情（\du 用户名）
若需查看某一用户的详细权限（如 test），执行 \du 用户名：
\du test
执行结果示例：
4.3 3. 查看用户的权限明细（\dp 命令）
若需更精细地查看用户对某类对象（如表、模式）的权限，可使用 \dp 命令：
-
查看表权限：
\dp 表名（如查看sys_user表的权限）；\dp test_schema.sys_user
五、修改用户：适配用户属性变更
业务需求发生改变的时候，要对用户属性做一些调整，比如重置密码或者增减创建数据库的权限，ALTER USER 这个核心语法包含一些常见的操作
5.1 1. 修改用户密码（最常用操作）
当用户忘了密码或者是到了规定的时间得要换密码时，管理员可以运行如下命令（拿 test 来举例）：
-- 语法：ALTER USER 用户名 WITH PASSWORD '新密码';
ALTER USER test WITH PASSWORD 'User1@New2024';
- 验证：修改之后，用户就能重新登录（用
ksql -d kingbase -U user1命令），然后输入新的密码来验证是否有效
5.2 2. 授予用户属性（如建库权限）
如果想要给 test 授予创建数据库的权限（之前没有这个权限）
-- 语法：ALTER USER 用户名 权限属性;
ALTER USER test CREATEDB;
- 验证：执行
\du test这条命令，在Attributes栏里能看到创建 DB这个选项，这就表明权限已经被添加了
5.3 3. 撤销用户属性（如收回建库权限）
若 test 不再需要建库权限，可收回：
-- 语法：ALTER USER 用户名 NO 权限属性;
ALTER USER test NOCREATEDB;
- 验证：执行
\du test，Attributes中的Create DB会消失。
5.4 4. 修改用户默认属性（如默认数据库）
将 user1 的默认数据库从 kingbase 改为 test（需确保 test_db 已存在）：
ALTER USER test SET DEFAULT DATABASE test;
- 验证：等用户
test下次登录的时候，只要用ksql -U user1这个命令，系统就会自动帮它连接到test这个数据库，不需要手动加上-d test这样的参数。
六、权限控制：授予与回收（核心环节）
权限控制处于用户运作的核心地位，要依照“数据库→模式→表”这样的层级来执行权限的赋予或者收回，从而保证用户只能对自身业务范畴之内的对象实施操作，有关GRANT（即赋予）和 REVOKE（即收回）的语法，下面将针对不同情形展开详细阐述
6.1 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 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 1. 基础语法（加 IF EXISTS 避免报错）
DROP USER IF EXISTS 用户名;
IF EXISTS：若用户不存在，仅提示警告（NOTICE: role "用户名" does not exist, skipping），不报错，避免中断后续操作。
7.2 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 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 数据库安全控制的能力，下一篇文章我们会学习“事务运作”，从而保证多操作情况下数据的一致性（就像转账业务里的“扣款”和“入账”必须一起完成或者一起不完成一样）
