SQL
KingbaseES ksql 指南：创建与管理索引和视图
本文介绍了 KingbaseES 数据库中 ksql 命令行对索引和视图的管理操作。内容涵盖索引类型、创建（普通、唯一、复合）、查看、维护及删除；视图的创建（基础、筛选、只读）、查询、修改与删除。同时包含常见问题排查如重复键名报错、关系对象不存在及只读视图更新限制。通过示例演示了如何优化查询性能并简化数据访问逻辑，适合初学者掌握数据库查询优化核心技能。
本文介绍了 KingbaseES 数据库中 ksql 命令行对索引和视图的管理操作。内容涵盖索引类型、创建（普通、唯一、复合）、查看、维护及删除；视图的创建（基础、筛选、只读）、查询、修改与删除。同时包含常见问题排查如重复键名报错、关系对象不存在及只读视图更新限制。通过示例演示了如何优化查询性能并简化数据访问逻辑，适合初学者掌握数据库查询优化核心技能。
掌握表的基本运作之后，若想优化查询效率并简化数据访问，就要去学习'索引'和'视图'的运用。索引类似于'书籍目录'，可以极大地加快查询速度；视图类似'数据窗口'，能够隐藏复杂的查询逻辑，还能控制数据的可见性。本文就'ksql 命令行操作索引与视图'展开论述，把从'作用到创建，再到查看，维持直至删除'的全过程拆解成实际操作步骤，并结合例子和避坑提示，以使初学者能够领悟并付诸实行。
索引和视图要依托已有的表，所以得先做好如下预备工作（参照第四篇'表的运作'相关内容），以防止在操作过程中因为依赖缺失而出现错误提示。
利用 ksql 建立与本地 KingbaseES 数据库的联系，转到先前所创建的 test_schema 模式当中，检查目标表是否确实存在（拿 sys_user 表来说，要是没有就再次创建它，或者用一个新的例子），这样做的目的是确保后续操作能够顺利执行。
-- 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 语句创建表，确保后续操作有载体。
为了后续可以检测索引的查询速度，并查看视图的数据展示情况，要给 sys_user 表增添大量模拟数据来做测试（能够添加上千条记录以模拟真实场景）。
-- 批量插入 10 条测试数据（可复制扩展）
INSERT INTO test_schema.sys_user (name, phone, email)
VALUES('张三','13800138000','[email protected]'),
('李四','13900139000','[email protected]'),
('王五','13700137000','[email protected]'),
('赵六','13600136000','[email protected]'),
('孙七','13500135000','[email protected]'),
('周八','13400134000','[email protected]'),
('吴九','13300133000','wuj [email protected]'),
('郑十','13200132000','[email protected]'),
('钱一','13100131000','[email protected]'),
('冯二','1300130000','[email protected]');
执行后提示 INSERT 0 10，表示数据插入成功，为后续操作提供测试基础。
索引是 KingbaseES 优化查询性能的核心手段 —— 当表数据量较大时（如 10 万条 +），无索引的查询会'全表扫描'（逐行查找），而有索引的查询会通过'索引目录'直接定位数据，速度提升成百上千倍。接下来我们按'创建→查看→维护→删除'展开讲解。
新手需先明确不同索引的作用，避免盲目创建（索引并非越多越好，会增加更新 / 插入的开销）：
给 sys_user 表的 phone 列建普通索引（频繁按手机号查用户时用）：
-- 语法：CREATE INDEX 索引名 ON 表名 (字段名);
CREATE INDEX idx_sys_user_phone ON test_schema.sys_user(phone);
成功验证：执行后提示 CREATE INDEX，表示索引创建成功。
给 sys_user 表的 email 列建唯一索引（既确保邮箱不重复，又加速邮箱查询）：
-- 语法：CREATE UNIQUE INDEX 索引名 ON 表名 (字段名);
CREATE UNIQUE INDEX idx_sys_user_email ON test_schema.sys_user(email);
与 UNIQUE 约束的区别：唯一索引只保证值唯一，UNIQUE 约束包含约束和唯一索引，如果表已有 email 的 UNIQUE 约束，则不必再创建 email 的唯一索引，因为约束本身就会生成索引。
为 sys_user 表的 name 和 create_time 列创建复合索引，当经常依照'姓名 + 创建时间范围'执行查询的时候会用到这个索引。
-- 语法：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 单字段查询，要按照查询习惯来确定字段顺序。
创建索引后，需通过 ksql 命令查看索引列表、关联表及详情，推荐 i 和 + 命令：
执行 i 可列出当前模式下的所有索引，确认索引是否创建成功：
\di
执行结果示例：
关键信息解读：
Table：索引关联的表（确认是 sys_user）；Columns：索引对应的字段（单字段 / 多字段）；sys_user_pkey：主键自动创建的索引（无需手动创建）。
若需查看某张表的所有索引（如 sys_user），执行 + 表名：
\d+ test_schema.sys_user
执行结果示例（索引部分）：
直接展示表关联的所有索引，包括类型（PRIMARY KEY/UNIQUE/ 普通）和字段，清晰直观。
索引经过一定时间的使用之后，有可能会出现由于数据频繁被删除或者更新而造成的'碎片化'现象，即索引文件中存在许多空白空间，这种情况下要借助重建索引来改善这种情况，而且按照个人需求也可以重新命名或者直接删除索引。
当索引查询速度变慢时，重建索引可整理碎片，恢复性能（表大时建议离线执行，避免影响业务）：
-- 语法：REINDEX INDEX 索引名;
REINDEX INDEX idx_sys_user_phone;
-- 进阶：重建表的所有索引（更高效）
REINDEX TABLE sys_user;
REINDEX，表示重建完成。索引名若不符合规范，可以重新命名，可以把 idx_sys_user_phone 改为 idx_sys_user_mobile。
-- 语法：ALTER INDEX 旧索引名 RENAME TO 新索引名;
ALTER INDEX idx_sys_user_phone RENAME TO idx_sys_user_mobile;
验证：执行 + test_schema.sys_user 可看到索引名已更新。
某字段查询频率降低或者索引致使插入/更新变慢的时候，要删除无用索引（要注意的是，主键索引以及与唯一约束相关联的索引不能直接删，应当先删约束）。
-- 语法：DROP INDEX IF EXISTS 索引名;
DROP INDEX IF EXISTS idx_sys_user_name_createtime;
IF EXISTS：避免索引不存在时报错，仅提示警告； + test_schema.sys_user 确认索引已移除。WHERE SUBSTR(phone,1,3) = '138' 这种情况会使索引失效，应该改成 WHERE phone LIKE '138%'（前缀符合能够利用索引）。视图属于'虚拟表'，它依靠 SQL 查询结果生成，并未储存实际数据（数据仍旧保存在原始表当中），其关键意义在于'隐匿复杂查询逻辑'以及'调控数据可见范围'（譬如仅仅向用户显示某些列），我们按照'创建 - 查看 - 操作 - 删除'的顺序来执行。
新手容易混淆'表'和'视图'，用通俗比喻理解：
视图的核心场景：
sys_user 表中 name 和 phone 字段的内容，而将 email 这类敏感信息遮盖起来，这要依靠视图来达成。创建'用户基础信息视图 vw_sys_user_basic'，只包含 id、name、phone 列（隐藏 email 敏感信息）：
-- 语法：CREATE VIEW 视图名 AS SELECT 语句;
CREATE VIEW vw_sys_user_basic AS
SELECT id, name, phone FROM test_schema.sys_user;
成功验证：执行后提示 CREATE VIEW，表示视图创建成功。
创建'2024 年创建的用户视图 vw_sys_user_2024'，筛选 create_time 在 2024 年的用户，包含 name、email、create_time 列：
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';
若需确保视图数据不被修改（如报表视图），可添加 WITH READ ONLY 选项：
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'。创建视图之后，要利用 ksql 命令来查看视图列表，定义以及相关联的表，建议使用 v 和 + 这两个命令。
执行 v 可列出当前模式下的所有视图，确认视图是否创建成功：
执行结果示例：
若需确认视图的底层 SQL（如忘记视图筛选条件），执行 + 视图名：
\d+ vw_sys_user_2024
执行结果示例（定义部分）：
直接展示视图的完整 SQL 定义，便于后续修改或验证逻辑。
视图的核心操作是'查询'，修改和删除需遵循特定规则。
查询视图数据的语法和查询表完全相同，无需额外学习：
-- 查询基础视图数据
SELECT * FROM vw_sys_user_basic;
-- 查询 2024 年用户视图，按创建时间排序
SELECT * FROM vw_sys_user_2024 ORDER BY create_time DESC;
email 在 vw_sys_user_basic 中不可见）。若需调整视图的筛选条件或列（如 vw_sys_user_2024 改为包含 2023 年数据），无需删除视图，直接用 CREATE OR REPLACE 修改：
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';
+ vw_sys_user_2024 确认定义已更新。当视图不再使用时，执行删除命令（删除视图不影响原表数据，仅删除视图定义）：
-- 语法：DROP VIEW IF EXISTS 视图名;
DROP VIEW IF EXISTS vw_sys_user_report;
v 确认视图已移除。READ ONLY）：
DISTINCT（去重），GROUP BY（分组），HAVING（筛选分组）。COUNT、SUM）；JOIN）；sys_user 表）被删除，则该视图就会成为'无效视图'，在执行查询的时候，会收到'relation does not exist'的错误提示。JOIN 操作里涉及的关联列就需要事先创建好索引。报错信息：
ERROR: duplicate key name "idx_sys_user_phone"
原因：同名索引已存在（如之前已创建 idx_sys_user_phone）。
解决方案：
i 查看索引名，确认是否重复；DROP INDEX idx_sys_user_phone;），再创建新索引。报错信息：
ERROR: relation "vw_sys_user_basic" does not exist
原因：
vw_sys_user_basci）；test_schema，但当前搜索路径是 public）。
解决方案： v 确认正确名称）；SET search_path TO test_schema, public;），或用'模式名。视图名'全称查询（SELECT * FROM test_schema.vw_sys_user_basic;）。报错信息：
ERROR: cannot update a read-only view "vw_sys_user_report"
原因：视图创建时加了 WITH READ ONLY 选项，禁止修改。
解决方案：
GROUP BY、聚合函数等）。若需允许修改，重新创建视图（去掉 WITH READ ONLY）：
CREATE OR REPLACE VIEW vw_sys_user_report AS
SELECT name, phone, create_time FROM sys_user;
本文完整覆盖了索引和视图的核心操作，核心要点可总结为：
vw_sys_user_2024 视图对应的 sys_user 原表创建 create_time 索引之后，其查询效率会得到很大的改善。掌握了索引和视图之后，你就具有了 KingbaseES 高效查询的关键能力，下篇文章我们会学习'用户与权限管理'，从而保障数据库访问的安全，并做到'不同用户访问不同数据'这样细致的控制。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
在线格式化和美化您的 SQL 查询（它支持各种 SQL 方言）。 在线工具，SQL 美化和格式化在线工具，online
解析 INSERT 等受限 SQL，导出为 CSV、JSON、XML、YAML、HTML 表格（见页内语法说明）。 在线工具，SQL 转 CSV/JSON/XML在线工具，online
CSV 与 JSON/XML/HTML/TSV/SQL 等互转，单页多 Tab。 在线工具，CSV 工具包在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online