KingbaseES数据库：ksql 命令行玩转索引与视图，从创建到避坑

xcLeigh2026-02-04 9:44

KingbaseES数据库：ksql 命令行玩转索引与视图，从创建到避坑

本文聚焦 KingbaseES 数据库中 ksql 命令行对索引与视图的操作，先介绍前置准备，需连接数据库切换至目标模式（如 test_schema），确认并创建 sys_user 表，插入测试数据。接着详解索引管理，涵盖普通、唯一、复合三类索引的创建方法，用 \di、\d + 命令查看索引，通过重建、重命名、删除进行维护，还给出索引数量不超 5 个、小表无需建索引等避坑提示。然后阐述视图管理，包括基础、进阶、只读视图的创建，用 \dv、\d + 命令查看，以及查询、修改、删除操作，强调视图修改限制等注意事项。最后排查高频报错，总结索引与视图配合使用要点，助力新手掌握高效查询技能。

前言

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

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

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

学会了表的基本操作后，要是想让查询更快、访问数据更省事，那"索引"和"视图"这俩好帮手可得好好学一学。说起来，索引就像咱们看书时的目录，翻找内容能省不少劲；视图呢，更像是个专属数据窗口，不仅能把复杂的查询逻辑藏起来，还能控制哪些数据能被看到。今天咱就专门聊聊"ksql命令行操作索引与视图"，从它们的作用、创建方法，到怎么查看、维护，最后怎么删除，一步步拆成实实在在的操作步骤，再配上例子和避坑小提示，保证新手朋友也能看懂、能用起来。

一、前置准备：确认操作基础（衔接前文，确保连贯）

索引和视图都得依托已有的表才能用，所以咱得先做好下面这些准备工作（大家可以参考第四篇"表的运作"的相关内容），别到时候操作半天，因为少了基础依赖弹出一堆错误提示，那就麻烦了。

1.1 连接数据库并切换目标模式

先用ksql连上本地的KingbaseES数据库，再切换到之前创建的test_schema模式里。接着得确认一下目标表在不在，就拿sys_user表举例，要是没有，要么重新建一个，要么换个新例子表，总之得保证后面的操作能顺利进行。

sql 复制代码 
-- 1. 连接数据库（若未连接）
ksql -d kingbase -U system
-- 2. 切换到 test_schema 模式
SET search_path TO test_schema, public;
-- 3. 确认目标表存在（如 sys_user 表）
\dt sys_user;
-- 若不存在，创建示例表（用于后续索引/视图操作）
CREATE TABLE IF NOT EXISTS sys_user (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    phone CHAR(11) UNIQUE NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) TABLESPACE test_ts;

执行完要是显示Table "test_schema.sys_user" does not exist，那就先执行上面的CREATE TABLE语句建表，有了表，后面的操作才有载体。

1.2 插入测试数据（用于验证索引/视图效果）

为了后面能测试索引的查询速度，也能看看视图展示数据的样子，得给sys_user表加些模拟数据。最好多加点，比如上千条，这样更贴近真实使用场景。

sql 复制代码 
-- 批量插入10条测试数据（可复制扩展）
INSERT INTO test_schema.sys_user (name, phone, email)
VALUES 
('张三', '13800138000', 'zhangsan@test.com'),
('李四', '13900139000', 'lisi@test.com'),
('王五', '13700137000', 'wangwu@test.com'),
('赵六', '13600136000', 'zhaoliu@test.com'),
('孙七', '13500135000', 'sunqi@test.com'),
('周八', '13400134000', 'zhouba@test.com'),
('吴九', '13300133000', 'wujiu@test.com'),
('郑十', '13200132000', 'zhengshi@test.com'),
('钱一', '13100131000', 'qianyi@test.com'),
('冯二', '1300130000', 'fenger@test.com');

执行后要是提示INSERT 0 10，那就说明数据插成功了，后面的测试就有了基础。

二、索引管理：给表"加目录"，加速查询

在KingbaseES里，想让查询变快，索引可是核心手段。你想啊，要是表的数据量大，比如有10万条以上，没索引的话，查询就得"全表扫描"，一条一条找，多慢啊；但有了索引就不一样了，相当于有了"目录"，直接定位到数据，速度能快成百上千倍。接下来咱就按"创建→查看→维护→删除"的顺序好好说说。

2.1 先懂基础：索引的类型与适用场景

新手朋友得先搞明白不同索引有啥用，可别瞎创建。要知道，索引不是越多越好，多了反而会增加数据更新、插入的开销。

2.2 创建索引：用CREATE INDEX语句

2.2.1 示例1：创建普通索引（加速单字段查询）

要是经常按手机号查用户，那给sys_user表的phone列建个普通索引就很合适。

sql 复制代码 
-- 语法：CREATE INDEX 索引名 ON 表名(字段名);
CREATE INDEX idx_sys_user_phone ON test_schema.sys_user(phone);
  • 索引名规范：建议用"idx_表名_字段名"这种格式，比如"idx_sys_user_phone"，一看就知道是"sys_user"表里"phone"列的索引，多好认。
  • 成功验证 ：执行后提示CREATE INDEX，那就说明索引建好了。
2.2.2 示例2：创建唯一索引（确保字段唯一+加速查询）

给sys_user表的email列建个唯一索引也不错，既能保证邮箱不重复，查邮箱的时候也能更快。

sql 复制代码 
-- 语法：CREATE UNIQUE INDEX 索引名 ON 表名(字段名);
CREATE UNIQUE INDEX idx_sys_user_email ON test_schema.sys_user(email);
  • 与UNIQUE约束的区别 ：这里得提醒一句，唯一索引只是保证值不重复，而UNIQUE约束里既包含了约束，也自带了唯一索引。所以要是表已经有email的UNIQUE约束，就不用再特意给email建唯一索引了，约束本身就会生成索引。
2.2.3 示例3：创建复合索引（加速多字段组合查询）

要是经常按"姓名+创建时间范围"查数据，那给sys_user表的name和create_time列建个复合索引就很实用。

sql 复制代码 
-- 语法：CREATE INDEX 索引名 ON 表名(字段1, 字段2);
CREATE INDEX idx_sys_user_name_createtime ON test_schema.sys_user(name, create_time);
  • 字段顺序注意：复合索引有个"最左符合原则"，比如这个索引(name, create_time)，能加快name单字段的查询，也能加快name+create_time组合的查询，但没法加快create_time单字段的查询。所以字段顺序得根据平时的查询习惯来定，可别搞反了。

2.3 查看索引：确认索引存在与关联表

建完索引，得用ksql命令看看索引列表、关联的表还有详细信息，推荐大家用\di和\dt+这两个命令，很好用。

2.3.1 示例1：查看所有索引（\di命令）

执行\di就能列出当前模式下的所有索引，能快速确认索引是不是建成功了。

sql 复制代码 
\di

执行结果示例关键信息解读：

  • Table：能看到索引关联的表，确认是不是sys_user表；
  • Columns：能知道索引对应的字段，是单字段还是多字段；
  • sys_user_pkey：这个是主键自动创建的索引，不用咱们手动建。
2.3.2 示例2：查看表关联的索引（\dt+表名）

要是想查看某张表的所有索引，比如sys_user表，执行\d+ 表名就行。

sql 复制代码 
\d+ test_schema.sys_user

执行结果示例（索引部分） ：

这样能直接看到表关联的所有索引，包括索引类型（是PRIMARY KEY、UNIQUE还是普通索引）和对应的字段，清晰又直观，一眼就能看明白。

2.4 索引维护：优化性能与调整结构

索引用久了，因为数据经常被删除、更新，可能会出现"碎片化"的情况，就是索引文件里有不少空白空间，这时候就得重建索引来改善。另外，要是想给索引重命名，或者删掉没用的索引，也有对应的方法。

2.4.1 示例1：重建索引（解决碎片化，提升查询速度）

要是感觉索引查询变慢了，重建索引就能整理碎片，让性能恢复。不过要注意，要是表很大，最好离线执行，别影响正常业务。

sql 复制代码 
-- 语法：REINDEX INDEX 索引名;
REINDEX INDEX idx_sys_user_phone;
-- 进阶：重建表的所有索引（更高效）
REINDEX TABLE sys_user;
  • 成功验证 ：执行后提示REINDEX，就说明重建完成了。
2.4.2 示例2：重命名索引（规范命名）

要是索引名不符合规范，比如想把idx_sys_user_phone改成idx_sys_user_mobile，直接重命名就行。

sql 复制代码 
-- 语法：ALTER INDEX 旧索引名 RENAME TO 新索引名;
ALTER INDEX idx_sys_user_phone RENAME TO idx_sys_user_mobile;
  • 验证 ：执行\d+ test_schema.sys_user，就能看到索引名已经更新了。
2.4.3 示例3：删除索引（无用索引清理）

要是某个字段查询频率变低了，或者因为索引导致数据插入、更新变慢，那就得把没用的索引删掉。不过要注意，主键索引和跟唯一约束相关的索引不能直接删，得先把约束删掉才行。

sql 复制代码 
-- 语法：DROP INDEX IF EXISTS 索引名;
DROP INDEX IF EXISTS idx_sys_user_name_createtime;
  • IF EXISTS：加这个是为了避免索引不存在的时候报错，只会提示个警告，很贴心；
  • 验证 ：执行\d+ test_schema.sys_user，确认索引已经删掉了就行。

2.5 索引使用注意事项（新手避坑指南）

  1. 千万别觉得索引越多越好，索引多了，数据插入、更新、删除的时候开销都会变大。毕竟数据一变，索引也得跟着同步更新，多费事儿啊。所以一张表的索引最好别超过5个。
  2. 小表就别建索引了，要是数据量不到1万条，全表扫描比用索引查还快。你想啊，用索引还得先找索引再找数据，多了一次IO操作，反而慢了。
  3. 经常更新的列别建索引，比如"订单状态"这种字段，每秒都可能变，给它建了索引，索引就得频繁同步更新，多影响整体性能啊。
  4. 别对索引字段用函数，比如WHERE SUBSTR(phone,1,3) = '138'这种写法，会让索引失效。改成WHERE phone LIKE '138%'就好，前缀匹配是能用到索引的。

三、视图管理：给数据"开窗口"，简化查询与控制权限

视图其实是"虚拟表"，它是根据SQL查询结果生成的，本身不存实际数据，数据还在原始表里。但它的用处可不小，能"隐藏复杂查询逻辑"，还能"控制数据可见范围"，比如只让用户看到某些列。下面咱就按"创建-查看-操作-删除"的顺序来讲。

3.1 先懂基础：视图的核心作用（新手必知）

新手朋友容易把"表"和"视图"搞混，我给大家打个通俗的比方：

  • 表就像"仓库"，里面实实在在存着数据；
  • 视图呢，就是"仓库窗口"，通过这个窗口只能看到指定区域的货物（数据），整个仓库的情况是看不到的。而且这个窗口不能直接改，想改仓库里的数据得通过窗口，但还有不少限制。

视图的核心使用场景有这几个：

  1. 简化复杂查询，要是有很多表关联查询（JOIN），可以把它封装成视图，后面查数据直接用视图就行，不用再写一遍复杂的SQL，多省事儿。
  2. 控制数据权限，比如想让普通用户只看到sys_user表里的name和phone字段，把email这种敏感信息藏起来，用视图就能做到。
  3. 保证数据一致性，要是多个系统都用同一个查询逻辑，用视图就能确保所有系统都用一样的筛选条件，不会出乱子。

3.2 创建视图：用CREATE VIEW语句

3.2.1 示例1：基础视图（简化单表查询）

咱创建一个"用户基础信息视图vw_sys_user_basic"，里面只包含id、name、phone列，把email这种敏感信息藏起来。

sql 复制代码 
-- 语法：CREATE VIEW 视图名 AS SELECT 语句;
CREATE VIEW vw_sys_user_basic AS
SELECT id, name, phone 
FROM test_schema.sys_user;
  • 成功验证 ：执行后提示CREATE VIEW，就说明视图建好了。
3.2.2 示例2：进阶视图（带筛选条件的复杂查询）

再创建一个"2024年创建的用户视图vw_sys_user_2024"，筛选出create_time在2024年的用户，里面包含name、email、create_time列。

sql 复制代码 
CREATE VIEW vw_sys_user_2024 AS
SELECT name, email, create_time 
FROM test_schema.sys_user 
WHERE create_time >= '2024-01-01 00:00:00' 
  AND create_time < '2025-01-01 00:00:00';
  • 动态性：这里得说一下，视图里的数据会跟着原表自动变。比如原表新增了一个2024年创建的用户，视图里也会自动包含这条数据，不用手动更新。
3.2.3 示例3：只读视图（禁止修改数据）

要是想确保视图里的数据不能被改，比如报表视图，那就加个WITH READ ONLY选项。

sql 复制代码 
CREATE VIEW vw_sys_user_report AS
SELECT name, phone, create_time 
FROM test_schema.sys_user 
WITH READ ONLY;
  • 效果 ：后面要是想通过这个视图改数据，比如执行UPDATE vw_sys_user_report SET name='张三'，就会报错"cannot update a read-only view"，根本改不了。

3.3 查看视图：确认视图定义与关联表

建完视图，得用ksql命令看看视图列表、定义还有关联的表，推荐用\dv和\d+这两个命令。

3.3.1 示例1：查看所有视图（\dv命令）

执行\dv就能列出当前模式下的所有视图，能快速确认视图是不是建成功了。

3.3.2 示例2：查看视图定义（\d+视图名）

要是忘了视图的筛选条件，想确认一下视图的底层SQL，执行\d+ 视图名就行。

sql 复制代码 
\d+ vw_sys_user_2024

执行结果示例（定义部分） ：

这样能直接看到视图完整的SQL定义，后面想修改或者验证逻辑都很方便。

3.4 视图操作：查询、修改与删除

视图最主要的操作是"查询"，修改和删除都有特定的规则，可不能随便来。

3.4.1 示例1：查询视图数据（与表查询一致）

查询视图数据的语法和查表一模一样，不用额外学新东西。

sql 复制代码 
-- 查询基础视图数据
SELECT * FROM vw_sys_user_basic;
-- 查询2024年用户视图，按创建时间排序
SELECT * FROM vw_sys_user_2024 ORDER BY create_time DESC;
  • 效果 ：返回的结果和查原表筛选后的数据一样，但看不到那些被隐藏的列，比如在vw_sys_user_basic里就看不到email列。
3.4.2 示例2：修改视图定义（CREATE OR REPLACE）

要是想调整视图的筛选条件或者包含的列，比如把vw_sys_user_2024改成包含2023年的数据，不用删了视图重新建，直接用CREATE OR REPLACE修改就行。

sql 复制代码 
CREATE OR REPLACE VIEW vw_sys_user_2024 AS
SELECT name, email, create_time 
FROM test_schema.sys_user 
WHERE create_time >= '2023-01-01 00:00:00' 
  AND create_time < '2025-01-01 00:00:00';
  • 验证 ：执行\d+ vw_sys_user_2024，确认视图定义已经更新了就行。
3.4.3 示例3：删除视图（DROP VIEW）

要是某个视图不用了，就把它删掉。放心，删除视图不会影响原表数据，只是把视图的定义删掉了。

sql 复制代码 
-- 语法：DROP VIEW IF EXISTS 视图名;
DROP VIEW IF EXISTS vw_sys_user_report;
  • 验证 ：执行\dv，确认视图已经删掉了就可以。

3.5 视图使用注意事项（新手避坑指南）

  1. 视图修改有不少限制，就算没加READ ONLY，只要有下面这些情况，也没法改数据：
    • 视图里包含DISTINCT（去重）、GROUP BY（分组）、HAVING（筛选分组）；
    • 视图里有聚合函数，比如COUNT、SUM；
    • 视图是从多个表关联（JOIN）来的；
  2. 要是原表被删了，比如sys_user表没了，那对应的视图就成了"无效视图"，再查这个视图就会报错"relation does not exist"。
  3. 性能方面也得注意，要是视图很复杂，包含多表关联或者聚合操作，它的查询效率就看原表有没有索引。所以原表里那些相关的字段，比如多表JOIN时用到的关联列，一定要提前建好索引。

四、常见问题排查：索引与视图的高频报错

问题1：创建索引报错"重复的键名"

报错信息：

plaintext 复制代码 
ERROR:  duplicate key name "idx_sys_user_phone"

原因 ：这明显是同名的索引已经存在了，比如之前已经创建过idx_sys_user_phone。
解决方案：

  • 先执行\di看看索引名，确认是不是真的重复了；
  • 要是想重新建这个索引，先把旧的删掉，执行DROP INDEX idx_sys_user_phone;，然后再建新的。

问题2：查询视图报错"关系对象不存在"

报错信息：

plaintext 复制代码 
ERROR:  relation "vw_sys_user_basic" does not exist

原因：

  1. 要么是视图名拼错了，比如把vw_sys_user_basic写成了vw_sys_user_basci；
  2. 要么是视图所在的模式不在搜索路径里，比如视图在test_schema模式下，但当前的搜索路径是public。
    解决方案：
  • 先检查视图名拼写对不对，执行\dv确认一下正确的名称；
  • 要么切换到视图所在的模式，执行SET search_path TO test_schema, public;；要么查询的时候用"模式名.视图名"的全称，比如SELECT * FROM test_schema.vw_sys_user_basic;。

问题3：通过视图修改数据报错"无法更新只读视图"

报错信息：

plaintext 复制代码 
ERROR:  cannot update a read-only view "vw_sys_user_report"

原因 ：这是因为创建视图的时候加了WITH READ ONLY选项，就是禁止修改的。
解决方案：

  • 要是想允许修改，就重新创建视图，把WITH READ ONLY去掉：

    sql 复制代码 
    CREATE OR REPLACE VIEW vw_sys_user_report AS
SELECT name, phone, create_time FROM sys_user;

  • 不过要注意，重新创建之前得确认这个视图没有其他修改限制，比如不含GROUP BY、聚合函数这些。

五、总结：索引与视图的配合使用

今天把索引和视图的核心操作都讲透了，核心要点总结一下：

  1. 索引：主要管"查询速度"，得根据查询场景选普通、唯一还是复合索引，别建太多，还得定时重建优化性能；
  2. 视图：主要管"查询简化和权限控制"，能把复杂逻辑封装起来，隐藏敏感数据，但要注意修改限制和对原表的依赖；
  3. 配合使用 ：视图的查询速度和原表的索引有关系，比如给vw_sys_user_2024视图对应的sys_user原表建个create_time索引，视图的查询效率能提升不少。

学会了索引和视图，你在KingbaseES里查数据就能又快又方便了。下一篇咱就讲"用户与权限管理"，让数据库访问更安全，实现"不同用户看不同数据"的精细控制。

联系博主

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

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

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

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

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

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

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

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

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

相关推荐
leisigoyle1 小时前
SQL Server 2025安装教程
大数据·运维·服务器·数据库·人工智能·计算机视觉·数据可视化
DO_Community2 小时前
教程：构建基于 Coreflux MQTT 与托管数据库的IoT数据管道
数据库·物联网
小Tomkk2 小时前
数据库 变更和版本控制管理工具 --Bytebase 使用指南
数据库·bytebase
DarkAthena2 小时前
【GaussDB】用AI解析UGO中的SQL审核模块的实现
数据库·sql·gaussdb
xdpcxq10292 小时前
MySQL 5.6 2000 万行高频读写表新增字段
数据库·mysql
huohuopro2 小时前
Redis安装和杂谈
数据库·redis·缓存
马猴烧酒.2 小时前
【团队空间|第十一天】基础功能实现，RBAC权限控制，ShardingSphere详解
java·开发语言·数据库
long3162 小时前
KMP模式搜索算法
数据库·算法
有味道的男人2 小时前
接入MIC（中国制造）接口的帮助
网络·数据库·制造
热门推荐
01GitHub 镜像站点02OpenCode 入门教程：介绍 · 安装 · 配置第三方 API (如 Claude)032025 年大语言模型发展回顾：关键突破、意外转折与 2026 年展望04Claude Code Skills 实用使用手册05Clawdbot 中文汉化版 接入微信、飞书06Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services07OpenClaw部署与配置教程：在Mac mini上接入国产大模型与飞书08在Trae中使用Pencil MCP09UV安装并设置国内源10一文了解国产算子编程语言 TileLang，TileLang 对国产开源生态的影响与启示