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

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

本文聚焦 KingbaseES 数据库的 ksql 命令行用户与权限管理，先明确操作前需用管理员账号（如 system）连接数据库，并确认依赖的数据库、模式、表等对象存在。接着解析权限 “数据库→模式→表” 的层级关系，再分步讲解用户管理全流程：创建用户时需设置用户名、密码及属性，可通过 \du 命令查看用户信息，用 ALTER USER 修改密码、权限属性及默认配置，按层级用 GRANT 授予、REVOKE 回收权限，删除用户需谨慎，存在依赖对象时需加 CASCADE 参数。还列举了登录、查表、删用户的常见报错及解决办法，强调最小权限、层级清晰等核心原则，助力新手掌握数据安全控制要点。

前言

    中电科金仓（北京）科技股份有限公司（以下简称“电科金仓”）成立于1999年，是成立最早的拥有自主知识产权的国产数据库企业，也是中国电子科技集团（CETC）成员企业。电科金仓以“提供卓越的数据库产品助力企业级应用高质量发展”为使命，致力于“成为世界卓越的数据库产品与服务提供商”。

    电科金仓自成立起始终坚持自主创新，专注数据库领域二十余载，具备出色的数据库产品研发及服务能力，核心产品金仓数据库管理系统KingbaseES（简称“KES”）是面向全行业、全客户关键应用的企业级大型通用数据库。KES产品V9版本已通过国家权威机构认证，产品核心源代码自主率达到100%。2018年，电科金仓申报的“数据库管理系统核心技术的创新与金仓数据库产业化”项目荣获国家科学技术进步二等奖。金仓数据库管理系统KES于2022年入选国务院国资委发布的十项国有企业数字技术典型成果，彰显数据库领域国家队硬实力。继2023年金仓数据库管理系统V8通过第一批《安全可靠测评》后，2024年金仓数据库管理系统V9、金仓分布式HTAP数据库软件集群V3再度入围，至此电科金仓共计2款产品3个版本通过《安全可靠测评》*。

🥇 点击进入金仓数据库专栏，本专栏聚焦金仓数据库（KingbaseES）这一国产企业级融合数据库，为开发者及技术决策者提供从基础操作到架构设计的系统化学习路径。从多语法兼容（Oracle/MySQL/PostgreSQL）、多模数据存储（关系 / 文档 / 时序 / GIS）等功能展开讲解！

搞定数据库、表、索引这些核心对象后，“用户与权限控制”就成了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 基础语法

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

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

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

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

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

CREATEUSER 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 '新密码';ALTERUSER test WITH PASSWORD 'User1@New2024';

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

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

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

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

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

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

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

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

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

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

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

ALTERUSER test SETDEFAULTDATABASE test;

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

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

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

6.1 授予权限（GRANT命令）

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

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

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

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

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

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

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

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

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

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

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

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

GRANTALLPRIVILEGESON test_schema.sys_user TO test;

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

6.2 回收权限（REVOKE命令）

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

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

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

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

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

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

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

DROPUSERIFEXISTS 用户名;

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

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

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

-- 语法：DROP USER IF EXISTS 用户名 CASCADE;DROPUSERIFEXISTS 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权限：

GRANTCONNECTONDATABASE kingbase TO user1;

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

报错信息：

ERROR: permission denied for schema test_schema 

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

GRANTUSAGEONSCHEMA test_schema TO user1;

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

报错信息：

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

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

DROPUSERIFEXISTS user1 CASCADE;

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

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

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

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

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

联系博主

    xcLeigh 博主，全栈领域优质创作者，博客专家，目前，活跃在ZEEKLOG、微信公众号、小红书、知乎、掘金、快手、思否、微博、51CTO、B站、腾讯云开发者社区、阿里云开发者社区等平台，全网拥有几十万的粉丝，全网统一IP为 xcLeigh。希望通过我的分享，让大家能在喜悦的情况下收获到有用的知识。主要分享编程、开发工具、算法、技术学习心得等内容。很多读者评价他的文章简洁易懂，尤其对于一些复杂的技术话题，他能通过通俗的语言来解释，帮助初学者更好地理解。博客通常也会涉及一些实践经验，项目分享以及解决实际开发中遇到的问题。如果你是开发领域的初学者，或者在学习一些新的编程语言或框架，关注他的文章对你有很大帮助。

    亲爱的朋友，无论前路如何漫长与崎岖，都请怀揣梦想的火种，因为在生活的广袤星空中，总有一颗属于你的璀璨星辰在熠熠生辉，静候你抵达。

     愿你在这纷繁世间，能时常收获微小而确定的幸福，如春日微风轻拂面庞，所有的疲惫与烦恼都能被温柔以待，内心永远充盈着安宁与慰藉。

    至此，文章已至尾声，而您的故事仍在续写，不知您对文中所叙有何独特见解？期待您在心中与我对话，开启思想的新交流。

     💞 关注博主 🌀 带你实现畅游前后端！

     🥇 从零到一学习Python 🌀 带你玩转Python技术流！

     🏆 人工智能学习合集 🌀 搭配实例教程与实战案例，帮你构建完整 AI 知识体系

     💦 注：本文撰写于ZEEKLOG平台,作者：xcLeigh（所有权归作者所有） ，https://xcleigh.blog.ZEEKLOG.net/，如果相关下载没有跳转，请查看这个地址，相关链接没有跳转，皆是抄袭本文，转载请备注本文原地址。

     📣 亲，码字不易，动动小手，欢迎 点赞 ➕ 收藏，如 🈶 问题请留言（或者关注下方公众号，看见后第一时间回复，还有海量编程资料等你来领！），博主看见后一定及时给您答复 💌💌💌