KingbaseES金仓数据库：ksql 命令行从建表到删表实践（含增删改查）实用指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“KingbaseES金仓数据库：ksql 命令行从建表到删表实践（含增删……”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

前言

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

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

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

落到代码里，表在 KingbaseES 里就是数据的“专属公寓”，所有业务数据都得乖乖住进这公寓里。今天咱就唠唠“用 ksql 命令行折腾表”的事儿，从“建表→看表结构→增删改查数据→改表结构→删表”这一整套流程，把每个步骤的实操方法、语法例子，还有怎么避开那些让人头大的坑，都给你讲明白。就算是刚摸 KingbaseES 的新手，看完也能轻松拿捏表的操作。

一、前置准备：确认操作环境（衔接前文，避免踩坑）

在这个场景下，在跟表较劲之前，有两件基础准备工作得先搞定（大家能够翻回第三篇“模式与表空间”的内容看看，这样操作能更顺），不随后面操作表的时候，指不定就卡壳了。

1.1 1. 连接本地数据库并切换目标模式

理解这一步时，先用 ksql 跟本地的 KingbaseES 数据库搭上线（咱就假设连的是 kingbase 库），再切到之前建好的 test_schema 模式。为啥要这么干？还不是为了防止表默认跑到 public 模式里，后续想给表分分类管理，可就麻烦了。

-- 1. 连接数据库（要是还没连上的话）
ksql -d kingbase -U system
-- 2. 切换到 test_schema 模式（没切换的话就执行这条）
SET search_path TO test_schema, public;
-- 验证：看看当前搜索路径，确认 test_schema 在里面
SHOW search_path;

执行完之后，要是显示 search_path = test_schema, public，那就说明模式切对了，后面新建的表，默认就会待在 test_schema 模式里，省得你后续到处找表。

1.2 2. 确认表空间（可选，优化存储）

要是你想把表放到之前建好的 test_ts 表空间（不是默认的 pg_default），第一步得先确认这表空间真的存在（用 db 命令就能查看），之后建表的时候，直接把表空间名写上就行，不用搞其他花里胡哨的设置。

二、新建表：用 CREATE TABLE 定义数据结构

从实现思路看，建表就像是给数据“搭公寓框架”，关键是把“表的列、数据类型还有约束”都定好。咱先聊聊“常用的数据类型”和“核心约束”，每个点都给你配个例子，好理解。

2.1 1. 先懂基础：常用数据类型与约束

在这个场景下，新手建表前，得先搞明白 KingbaseES 常用的数据类型和约束，不然选错类型或者漏了约束，后面数据出问题，哭都来不及。

2.2 2. 基础示例：新建轻松表（含常用约束）

咱就以建个“用户表 user_info”为例，里面包含 id（主键，用来唯一标识用户）、name（非空，用户姓名不能空着）、age（有 CHECK 约束，得在合理范围）、phone（唯一，手机号不能重复）、create_time（默认当前时间，不用手动填），命令长这样：

CREATE TABLE user_info (
    -- 主键：唯一标识用户，自增（SERIAL 会自动建个序列，不用你手动指定ID，省事儿）
    id SERIAL PRIMARY KEY,
    -- 姓名：非空，最长50个字符
    name VARCHAR(50) NOT NULL,
    -- 年龄：得在1到150之间（这就是CHECK约束，防止填个几百岁的年龄）
    age INT CHECK (age > 0 AND age <= 150),
    -- 手机号：唯一，11位固定长度（用CHAR比VARCHAR合适，毕竟手机号都是11位）
    phone CHAR(11) UNIQUE,
    -- 创建时间：默认当前时间（TIMESTAMP DEFAULT CURRENT_TIMESTAMP，不用手动录时间）
    create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) 
-- 可选：指定表空间（用之前建的 test_ts）
TABLESPACE test_ts;

关键细节得拎清：

• SERIAL 是 KingbaseES 特有的自增类型，本质就是 INT 加个序列。往表里插数据的时候，不用手动填 id，数据库会自己生成一个唯一的数，多省心。
• DEFAULT CURRENT_TIMESTAMP 意思是，插数据的时候要是没填 create_time，数据库会自动把当前时间填进去，不用你记着录时间。
• TABLESPACE test_ts 就是说这表放 test_ts 表空间里，要是没指定，就默认待 pg_default 里。
  成功没？看这就行：
  执行完之后，要是提示 CREATE TABLE，那就是表建好啦。后面用“查看表结构”的命令，就能确认这表是不是跟你想的一样。

2.3 3. 进阶示例：新建复合主键表（多字段唯一）

理解这一步时，有时候业务要求“好几个字段放一起得唯一”（比如“订单明细表 order_detail”，就得 order_id + product_id 唯一），这时候就得建复合主键，命令是这样的：

CREATE TABLE order_detail (
    order_id INT NOT NULL,
    product_id INT NOT NULL,
    product_name VARCHAR(100) NOT NULL,
    quantity INT NOT NULL CHECK (quantity >= 1),
    price NUMERIC(10,2) NOT NULL CHECK (price >= 0),
    -- 复合主键：order_id + product_id 放一起唯一
    PRIMARY KEY (order_id, product_id)
) TABLESPACE test_ts;

这儿的主键是 order_id 和 product_id 一起构成的，这样就能保证同一个订单里，不会出现重复的商品记录，避免后续算订单金额的时候出乱子。

三、查看表结构：确认表定义是否正确

实际处理时，表建好之后，得用 ksql 命令看看表的“基本结构”“详细信息”还有“表列表”，确保表的列、约束、表空间这些都跟你预期的一样。这里面有 dt、d、d+ 三个核心命令，咱一个一个说。

3.1 1. 查看当前模式下的表列表（dt）

执行 dt 命令，就能列出当前模式（也就是 test_schema）下所有的表，一眼就能看出你建的表在不在里面。

dt

执行结果大概长这样：
从实现思路看，会显示出当前模式下的表名、表类型、所有者、表空间这些信息，比如能看到 user_info 和 order_detail 这两个刚建的表都在列表里。

3.2 2. 查看表的基本结构（d 表名）

执行 d 表名 这个命令，能看到表的“列名、数据类型、约束”这些关键信息，平时看表结构，用这个命令最多。

d user_info

执行结果大概长这样：
会清晰列出 user_info 表每一列的列名、数据类型，还有主键、非空、CHECK、唯一这些约束，比如能看到 id 是 SERIAL 类型且为主键，name 是 VARCHAR(50) 且非空。

3.3 3. 查看表的详细信息（d+ 表名）

从实现思路看，要是想知道表的“存储大小、注释、所有者”这些更细的信息，那就执行 d+ 表名 命令。

d+ user_info

执行结果大概长这样：
在这个场景下，除了基本结构里的信息，还会多出存储方式（比如 plain 适合小数据，extended 适合大数据压缩）、表空间（能明确看到表在 test_ts 里）、表的大小、新建时间这些信息，想全面了解表，就看这个。

四、表数据操作：增删改查（CRUD）实战

落到代码里，表建好之后，核心就是对数据进行“插入（Create）、查询（Read）、更新（Update）、删除（Delete）”操作，这可是平时业务里最常干的活。每个步骤咱都配语法例子，再说说需留意的风险点，别踩坑。

4.1 1. 插入数据（INSERT）：向表中添加记录

4.1.1 基础示例：单条数据插入

往 user_info 表里插一条用户数据（id 是自增的，不用填；create_time 有默认值，也能省了），命令这么写：

INSERT INTO user_info (name, age, phone)
VALUES ('张三', 25, '13800138000');

执行完之后，要是没报错，那这条数据就插进去啦。

4.1.2 进阶示例：多条数据批量插入

落到代码里，批量插数据比一条一条插快多了，只要在 VALUES 后面用逗号把多条记录分开就行：

INSERT INTO user_info (name, age, phone)
VALUES 
('李四', 30, '13900139000'),
('王五', 28, '13700137000'),
('赵六', 35, '13600136000');

成功没？看提示：
执行完要是提示 INSERT 0 3（后面的数字就是插进去的行数），那就说明三条数据都插成功了，效率是不是比一条一条插高多了？

4.2 2. 查询数据（SELECT）：拿到表中记录

SELECT 这命令可灵活了，能“查所有列、查指定列、按条件筛数据、给数据排序、限制查出来的条数”，咱举几个常用的例子。

4.2.1 基础：查询所有记录（慎用！大表会卡死）

-- 查询 user_info 表所有列的所有记录
SELECT * FROM user_info;

理解这一步时，提醒一句，要是表特别大，数据成千上万条，用这个命令查，数据刷起来没完，还可能把数据库搞卡，所以非必要别用。

4.2.2 常用：查询指定列 + 条件过滤

从实现思路看，比如你想“查年龄大于 28 的用户，只看 name、age、phone 这三列”，命令这么写：

SELECT name, age, phone 
FROM user_info 
WHERE age > 28;

从实现思路看，执行完之后，就只会显示符合“年龄大于28”条件的用户，而且只显示你指定的三列，不用看一堆没用的信息。

4.2.3 进阶：排序 + 限制条数

结合项目来看，再比如“查年龄大于 25 的用户，按年龄从大到小排序，只看前 2 条”，命令是这样的：

SELECT name, age, phone 
FROM user_info 
WHERE age > 25 
ORDER BY age DESC 
LIMIT 2;

执行结果大概长这样：
结合项目来看，会显示出年龄大于25的用户，按年龄从大到小排好序，而且只显示前两条，比如可能会先显示赵六（35岁），再显示李四（30岁）。

4.3 3. 更新数据（UPDATE）：修改已有记录

更新数据的时候，一定要加 WHERE 条件！ 不然没条件限制，会把表里所有记录都改了，那麻烦可就大了，哭都来不及。
例子：把“张三”的年龄改成 26

UPDATE user_info 
SET age = 26 
WHERE name = '张三'; -- 条件：只改姓名是“张三”的记录

成功没？这么验证：
执行完要是提示 UPDATE 1（意思是改了1行数据），那就改成功了。再用 SELECT 命令查查：

SELECT name, age FROM user_info WHERE name = '张三';

就能看到张三的年龄已经变成26了，没改错人。

4.4 4. 删除数据（DELETE）：移除表中记录

跟更新数据一样，删除数据也必须加 WHERE 条件，不然会把表里所有数据都删了，而且删了之后还找不回来，千万别手滑！
例子：删除手机号是“13700137000”的用户

DELETE FROM user_info 
WHERE phone = '13700137000'; -- 条件：只删手机号是这个的记录

成功没？这么验证：
执行完要是提示 DELETE 1，那就说明删成功了。再执行 SELECT * FROM user_info 看看，就能确认那个手机号对应的用户已经没了。

五、修改表结构（ALTER TABLE）：适配业务变更

落到代码里，业务需求一变，表结构也得跟着改（比如加个列、改列的类型、删个列啥的）。咱说说平时最常用的几种情况，别到时候业务变了，你还不知道怎么改表。

5.1 1. 添加列（ADD COLUMN）

比如给 user_info 表加个“邮箱列 email”（要求邮箱唯一，允许空着），命令这么写：

ALTER TABLE user_info 
ADD COLUMN email VARCHAR(100) UNIQUE;

验证：
执行 d user_info 看看，就能看到新增的 email 列已经在表里了，而且有唯一约束。

5.2 2. 修改列（ALTER COLUMN）

5.2.1 示例 1：修改列长度（比如把name列从 50 改成 100）

从实现思路看，有时候用户姓名太长，原来的 50 个字符不够用，那就得把列长度改大，命令是这样的：

ALTER TABLE user_info 
ALTER COLUMN name TYPE VARCHAR(100);

改完之后，name 列就能存最长 100 个字符的姓名了，不用再担心名字太长存不下。

5.2.2 示例 2：修改列默认值（比如把create_time默认值改成CURRENT_DATE）

理解这一步时，要是业务只需记录日期，不用精确到时间，那就把 create_time 的默认值改成只取当前日期，命令这么写：

ALTER TABLE user_info 
ALTER COLUMN create_time SET DEFAULT CURRENT_DATE;

注意：
落到代码里，改列类型的时候，得确保表里已经有的数据能兼容新类型。比如原来 name 列是 VARCHAR(10)，你想改成 INT，可列里存的都是“张三”“李四”这种文字，肯定改不了，还会报错，这点可得注意。

5.3 3. 删除列（DROP COLUMN）

比如想把 user_info 表的 age 列删了（提醒一句，列删了之后，里面的数据也跟着没了，而且找不回来，一定要想清楚再删），命令是这样的：

ALTER TABLE user_info 
DROP COLUMN IF EXISTS age; -- IF EXISTS 是怕列本来就不存在，执行命令的时候报错

验证：
执行 d user_info 看看，就能发现 age 列已经从表里消失了。

5.4 4. 添加约束（ADD CONSTRAINT）

比如想给 email 列加个“非空约束”（要求插数据的时候必须填邮箱，不能空着），命令这么写：

ALTER TABLE user_info 
ADD CONSTRAINT user_info_email_not_null CHECK (email IS NOT NULL);

验证：
执行 d user_info，在“Check constraints”那部分，就能看到新增的这个非空约束。
得注意：KingbaseES 的 CHECK 约束是“马上生效”的，加约束的时候，会把表里所有旧数据都检查一遍，确保都符合约束要求，这样能保证数据是一致的。要是你想让这约束只对以后新增的数据生效，不管旧数据是不是符合，那 KingbaseES 可没这功能，只能先把旧数据改好，符合约束了，再建这个约束。

5.5 5. 修改表名（RENAME TO）

比如想把 user_info 表改名叫 sys_user（可能是为了跟系统里其他表的命名规则统一），命令这么写：

ALTER TABLE user_info 
RENAME TO sys_user;

验证：
执行 dt 看看，就能发现表名已经从 user_info 变成 sys_user 了，改得明明白白。

六、删除表（DROP TABLE）：高危操作！

落到代码里，删表可是个高危操作，表一删，表结构、表里的数据，还有跟表关联的索引、约束，全没了，而且找不回来。所以删表之前，一定要把数据备份好，别脑子一热就删了。

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

DROP TABLE IF EXISTS sys_user; -- IF EXISTS：要是表本来就不存在，执行命令的时候只会给个警告，不会报错，省得你白担心

执行这条命令之前，再确认一遍数据备份好了，而且这表确实没用了，再下手。

6.2 级联删除（CASCADE）：删除依赖对象

实际处理时，有时候这表被视图、外键啥的依赖着，你直接删表，会报错删不了。这时候要是真想删，就得加 CASCADE 级联删除，把依赖这表的对象也一起删了（这操作更危险！千万别随便用）：

DROP TABLE IF EXISTS sys_user CASCADE;

警告：
CASCADE 一加上，所有依赖这表的对象（比如基于这表建的视图、跟这表有外键关联的其他表）都会被一起删掉。除非你能百分百确定这些依赖对象都没用了，否则绝对不能用这个命令，不然删错了，哭都没地方哭。

七、常用问题排查：新手常踩的坑

问题 1：插入数据报错 “重复键值违反唯一性约束”

报错信息：

ERROR:  duplicate key value violates unique constraint "user_info_phone_key"
DETAIL:  Key (phone)=(13800138000) already exists.

原因：你想插的手机号，表里已经有了，违反了 phone 列的唯一约束，数据库肯定不让插啊。
解决方案：要么把要插的手机号改成表里没有的，要么先把表里那个重复的手机号对应的记录删了，再插新数据。

问题 2：更新数据报错 “检查约束被违反”

报错信息：

ERROR:  check constraint "user_info_age_check" violated
DETAIL:  Failing row contains (2, 张三, 160, 13800138000, 2024-05-20).

原因：你想把张三的年龄改成 160，可之前建表的时候给 age 列加了 CHECK 约束，要求年龄在 1 到 150 之间，160 超出范围了，肯定改不了。
解决方案：把要改的年龄改成符合约束的，比如改成 50、60，只要在 1 到 150 之间就行。

问题 3：修改列类型报错 “无法修改被视图或规则引用的列的类型”

报错信息：

ERROR:  cannot alter type of a column used by a view or rule
DETAIL:  column "name" is used by view vw_user.

原因：你想改的 name 列，被一个叫 vw_user 的视图用着了，这种情况下，数据库不让直接改列类型，怕把视图搞坏了。
解决方案：先把依赖这列的视图删了（比如执行 DROP VIEW vw_user;），再去改列类型，改完之后要是还需那个视图，再重新建一个就行。

总结

从实现思路看，咱今天把表的“新建→查看→数据操作→结构修改→删除”全流程都讲了一遍，核心要点总结一下，便于你记：

1. 新建表：得把数据类型和约束搞清楚，再结合模式和表空间，这样后续管理表的时候能更有条理，不用东找西找。
2. 数据操作：主要就是 INSERT、UPDATE、DELETE 这三个命令。格式得记对，尤其是 UPDATE 和 DELETE，一定要加 WHERE 条件，不然一不小心就把所有数据改了或删了，哭都来不及。
3. 修改结构：用 ALTER TABLE 能灵活改表结构，但改的时候得注意数据兼容性，别因为改结构把原来的数据搞坏了。
4. 删除表：这可是高危操作，删之前必须把数据备份好，而且 CASCADE 级联删除千万别随便用，不然删错了就麻烦了。

在这个场景下，表在 KingbaseES 数据存储里可是核心角色，掌握了表的操作方法，后面用数据库就能顺手多了。

到此这篇关于KingbaseES金仓数据库：ksql 命令行从建表到删表实战（含增删改查）的文章就介绍到这了,更多相关KingbaseES采用ksql 命令行内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！