数据库行标识符机制探究：OID、ROWID与自增主键的实现与应用

深入解析KingbaseES中的行标识符OID与ROWID在数据库这个领域里咱们都知道怎么给每一行数据一个独一无二的“身份证”是保证数据靠谱不混乱、操作流畅又高效的根本。KingbaseESKES作为咱们自家的国产数据库在处理这个事儿上有不少自己的门道儿。其中对象标识符OID和行标识符ROWID就是它内部管理和元数据访问的两员“大将”。今天这篇分享我就从技术实现的角度带大家把KingbaseES里OID和ROWID这俩概念的底层原理给掰扯清楚。咱们一起来看看它们各自都有啥特点、适合用在哪些场合还有它们之间那些微妙的“关系”。我会详细说说OID在系统表和用户表里表现为啥不一样以及KES特有的ROWID机制包括它的数据类型、操作规范还有它俩在GUC参数配置上可能闹的“小矛盾”。当然啦咱们还会把OID、ROWID和大家更熟悉的自增主键放一块儿比一比再瞅瞅怎么用这些标识符来查询和解析数据库的元数据。希望通过我这篇唠嗑式的分享能帮大家对KingbaseES行标识符管理的技术细节有个更全面的认识往后在数据库设计、开发和优化的时候也能做得更明白、更到位。文章目录深入解析KingbaseES中的行标识符OID与ROWID1. KingbaseES中的对象标识符OID1.1 OID概述1.2 OID的创建与可见性1.3 OID的范围特性全局与局部1.4 OID的特性与使用考量1.5 regclassOID的便捷别名2. KingbaseES中的行标识符ROWID2.1 ROWID的创建方式2.2 ROWID与OID的参数治理冲突2.3 ROWID数据类型深度解析2.4 ROWID的操作与使用注意事项3. 核心存储机制对比OID、ROWID与自增主键3.1 OID (Object Identifier)3.2 ROWID (Row Identifier)3.3 自增主键 (SERIAL/BIGSERIAL)3.4 机制对比总结3.5 什么时候该选哪种机制4. 元数据访问与系统表解析4.1 深入理解系统表4.2 利用OID和regclass进行元数据查询4.3 元数据访问的意义5. 兼容性与参数治理GUC参数冲突5.1 行标识符相关的GUC参数5.2 GUC参数冲突解决机制5.3 参数配置的最佳实践总结1. KingbaseES中的对象标识符OID在数据库系统里头给每一行数据一个唯一的身份标识这活儿是核心中的核心。KingbaseESKES在这方面提供了好几种方法其中对象标识符OID就是它内部管理和元数据访问的一个重要角色。1.1 OID概述OIDObject Identifier翻译过来就是对象标识符它是KingbaseES内部用来给数据库对象比如表、视图、存储过程这些和数据行打标签的一个4字节长的标识符。在KES里头系统表和视图天生就带着OID而且还把它当主键用。不过话说回来对于咱们自己建的普通用户表OID默认可是不会露脸的也不是所有表都自动配有这玩意儿。KES版本验证我写这篇东西的时候是基于下面这个KingbaseES版本做的验证selectversion();1.2 OID的创建与可见性咱们自己建的普通表默认可是没有OID的。如果你想让某个表带上OID有两种方法一个是在建表的时候用上WITH OIDS这个子句另一个是把GUC参数default_with_oids给设置成true。示例默认情况下普通表不带OIDcreatetablett5(idint);insertintott5values(10);selectoid,idfromtt5;从上边这个例子咱们就能看出来直接去查tt5表的oid列会报错这说明这列压根儿就不存在。示例通过设置default_with_oids启用OIDsetdefault_with_oidstotrue;createtablett6(idint);insertintott6values(10);selectoidfromtt6;select*fromtt6;当default_with_oids被设置成true之后新创建的tt6表就自动有了OID。虽然你用select *是看不到OID列的但直接查询oid这个伪列是没问题的。示例通过CREATE TABLE ... WITH OIDS启用OIDsetdefault_with_oidstofalse;createtablett7(idint)withoids;insertintott7values(10);selectoid,idfromtt7;哪怕default_with_oids是false用WITH OIDS这个子句照样可以给指定的表配上OID。1.3 OID的范围特性全局与局部OID在KingbaseES里头它的“地盘”大小可不太一样理解这一点对咱们搞清楚它该用在哪很重要。系统表中的OID全局且连续对于系统表来说OID是全局唯一的而且分配的时候大体上是连续的。这就意味着不同系统表里的对象它们的OID值可能是挨着的。---创建一个自定义集合类型查看其在sys_type 中的OIDcreatetypeaatypistableofint;selectoid,typnamefromsys_typewheretypnameaatyp;---创建一个自定义函数查看其在sys_proc 中的OIDcreateorreplacefunctionfunc_test05(iint)returnsintas$$beginreturn1;end;$$languageplpgsql;selectoid,pronamefromsys_procwherepronamefunc_test05;从上面这个例子咱们就能发现新创建的类型aatyp和函数func_test05在它们各自的系统表sys_type和sys_proc里拿到的OID是连着的55136和55137这正好印证了系统表OID的全局连续性。普通表中的OID局部跟系统表不一样KingbaseES里普通表的OID是“各自为政”的也就是说每个普通表都有自己的OID序列跟别的表不掺和。这意味着哪怕两个不同的普通表都启用了OID它们的OID序列也是各自从1开始重新计数的。1.4 OID的特性与使用考量顺序分配与潜在重复OID是挨着顺序分配的4字节整数。虽然说在整个数据库实例里头最开始的时候它确实是唯一的但这个计数器大概数到42.9亿左右的时候就有可能转回来重新开始出现重复。唯一性保障要是担心单个表里头的OID出现重复你可以在OID列上建一个唯一索引。系统在插入新行的时候会检查OID是不是唯一的如果发现重复了它会重新给你生成一个直到找到不重复的为止。不过话又说回来如果表里的数据量特别大这个反复尝试的过程效率可就高不到哪儿去了。推荐实践对于用户表里头需要唯一行编号的情况官方建议咱们用SERIAL或者BIGSERIAL这种数据类型来当主键别太依赖OID。SERIAL适合估计数据量不会超过20亿的表而BIGSERIAL呢则是给那些数据量可能超过20亿的表准备的它能提供更靠谱的唯一性保证。1.5regclassOID的便捷别名regclass这个数据类型挺特别的它能让咱们直接用对象的名字来引用它的OID这样一来查询系统元数据可就方便多了。像表、索引、视图这些对象的标识符说白了就是系统表sys_class里头oid字段的值。为了给大家演示regclass怎么用我先建一个示例表teachersCREATETABLEteachers(teacher_idINTPRIMARYKEY,teacher_nameVARCHAR(100),ageINT,salINT,genderVARCHAR(10),titleVARCHAR(100),positionVARCHAR(100),departmentVARCHAR(100));INSERTINTOteachers(teacher_id,teacher_name,age,sal,gender,title,position,department)VALUES(1,张老师,35,8000,男,教授,系主任,计算机科学),(2,李老师,42,9500,女,副教授,教研室主任,软件工程),(3,王老师,28,6000,男,讲师,辅导员,信息管理);示例查询sys_class获取表OIDSELECToidFROMsys_classWHERErelnameteachers;示例使用regclass转换OID到表名---查询标识符(OID)为16700的表名select16700::regclass;通过::regclass这个类型转换咱们就能直接把OID变成对应的对象名称省事儿示例用regclass简化元数据查询以前那种老方法要查表的字段信息得把sys_attribute和sys_class这两个表关联起来查SELECTattrelid,attname,atttypid,attlen,attnum,attnotnullFROMsys_attributeWHEREattrelid(SELECToidFROMsys_classWHERErelnameteachers);但要是用上regclass类型转换这个查询就能变得简洁多了SELECTattname,atttypid,attlen,attnum,attnotnullFROMsys_attributeWHEREattrelidteachers::regclass;这里的teachers::regclass实际上跟SELECT oid FROM sys_class WHERE relnameteachers是一个意思它返回的就是teachers表的OID这样一来元数据查询的写法可就清爽多了。2. KingbaseES中的行标识符ROWID除了OIDKingbaseES还整了个ROWID机制专门用来给数据库里每一条记录当“身份证”。ROWID是个伪列它在逻辑上给每一行数据一个唯一标识但不像普通列那样实实在在地存在表里头。虽然咱们能查到ROWID的值但不能直接往里插、改或者删。2.1 ROWID的创建方式KingbaseES提供了多种方式来为表启用ROWIDGUC参数default_with_rowid当此参数设置为true时所有新创建的表都会自动增加一个名为“ROWID”的隐含列其类型为ROWID TYPE。所有插入的数据其ROWID都会被写入到该列中。示例通过GUC参数启用ROWIDset default_with_rowid to true;create table tt_rowid_guc(id int);insert into tt_rowid_guc values(10);select rowid,id from tt_rowid_guc;2. **CREATE TABLE ... WITH ROWID语句** 如果不想全局启用ROWID可以在创建特定表时使用WITH ROWID子句来为其添加ROWID列。 **示例通过CREATE TABLE ... WITH ROWID创建** sql create table student(sno int, name varchar(10), birthday date, department varchar(10), sex varchar(10)) with rowid; insert into student values(1, li, 2018-1-1, physics, boy); insert into student values(5, lu, 2018-1-2, chinese, boy); select rowid, * from student;有个地方得提一下当表创建了ROWID之后KingbaseES会默认给它建一个带唯一约束的B-tree索引这样查询性能就能上去。 sql\d student3. **ALTER TABLE ... SET WITH ROWID语句** 对于已经存在的表可以通过ALTER TABLE语句来添加ROWID列。 **示例对已有表添加ROWID** sql create table existing_table(id int); alter table existing_table set with rowid; insert into existing_table values(1); select rowid, id from existing_table;2.2 ROWID与OID的参数治理冲突在KingbaseES里头default_with_rowid和default_with_oids这俩GUC参数都是管表是不是默认带行标识符的。不过话说回来它们俩不能同时起作用default_with_rowid这个参数的优先级比default_with_oids要高。示例参数冲突时的行为-- 检查当前参数设置showdefault_with_oids;showdefault_with_rowid;-- 在两个参数都为on的情况下创建表createtablett_conflict(idint);insertintott_conflictvalues(10);-- 查询ROWID成功selectrowid,idfromtt_conflict;-- 查询OID失败selectoid,idfromtt_conflict;从上述示例可以看出尽管default_with_oids为on但由于default_with_rowid也为on新创建的表tt11会默认带有ROWID而不会带有OID这表明ROWID的优先级更高。还有啊如果default_with_rowid是false而default_with_oids是true这时候你还想用CREATE TABLE ... WITH ROWID系统可是会报错的。sql set default_with_rowid to false; set default_with_oids to true; create table tt_explicit_rowid(id int) with rowid;这个错误信息明确指出在default_with_rowid为false且default_with_oids为true的情况下不能显式地创建带有ROWID的表。2.3 ROWID数据类型深度解析KingbaseES的ROWID类型数据表示行记录在数据库中的逻辑唯一标识。它并非物理地址而是通过内部复合结构存储并通过64进制字符进行表示。表示形式ROWID通常以23个字符的64进制字符串表示包含A-Z, a-z, 0-9, 以及/符号。存储方式实际存储采用变长方式占用4到18个字节。内部结构ROWID类型的数据通过内部复合结构存储包含以下信息事务的回卷次数0-5位元组插入时的XID6-11位事务内已插入元组的个数12-22位编码格式事务回卷次数和XID采用32位编码事务内元组个数采用64位编码。ROWID范围Min:AAAAAA AAAAAB AAAAAAAAAAAMax:D////// D////// P//////////超出此范围的ROWID被视为非法格式。事务内元组计数每次开启新的事务包括子事务事务内已插入元组的个数都会重新计算。示例ROWID的导入与导出CREATETABLErowid_tt1(id rowid);-- 导入ROWID\echoecho AAAAAAAAAAABAAAAAAAAAAA /tmp/rowid_tt1.txtCOPY rowid_tt1FROM/tmp/rowid_tt1.txt;select*fromrowid_tt1;-- 导出ROWIDcopy rowid_tt1to/tmp/rowid_tt1_to.txt;\echomore /tmp/rowid_tt1_to.txt示例ROWID数据类型校验ROWID的字符数必须是23个否则无法正常插入。insertintorowid_tt1values(AAAAAAAAAAABAAAAAAAAAAA44444444);insertintorowid_tt1values(AAAAAAAAAAABAAAAA);2.4 ROWID的操作与使用注意事项ROWID支持特定的操作符和使用场景投影列支持在SELECT语句中作为投影列查询当前行的逻辑ID。过滤条件支持在WHERE子句中使用ROWID进行条件过滤例如ROWID OP CONST或CONST OP ROWID的形式其中OP只支持关系运算符,,,,,!等。排序与分组支持在ORDER BY和GROUP BY子句中使用ROWID。存储过程可以在存储过程中结合上述1、2、3点使用。不支持运算ROWID不支持与关系运算符以外的其他运算符进行运算。索引支持ROWID支持BTREE和HASH索引这有助于提高基于ROWID的查询性能。示例ROWID的比较操作select*fromrowid_tt1;select*fromrowid_tt1whereidAAAAAAAAAAABAAAAAAAAAAB;原则上后插入的数据的ROWID要大于先插入的ROWID即ROWID属于单调递增的数据。3. 核心存储机制对比OID、ROWID与自增主键在KingbaseES里头给行加标识符有好几种方法每种方法设计的时候都有自己特定的目的适合用在不同场合。咱们要是能把OID、ROWID还有自增主键比如SERIAL/BIGSERIAL这仨之间的相同点和不同点搞清楚对数据库设计和性能优化来说那可是相当重要的。3.1 OID (Object Identifier)定义与特性OID是KingbaseES内部用来给数据库对象和数据行打标签的4字节整数。它在系统表里当主键用具有全局唯一性。但如果是用户表要是通过WITH OIDS或者default_with_oids给启用了那它的OID可就只在这一个表里有效了而且等数到42.9亿左右的时候还可能转回来重复。存储OID作为伪列存在如果启用会为每行分配一个4字节的存储空间。唯一性与可靠性理论上全局唯一但对于用户表其局部性及潜在的重复风险使其不适合作为业务主键。虽然可以通过唯一索引强制唯一但这会带来性能开销。主要用途主要用于系统内部管理和元数据访问例如通过regclass类型快速查询对象信息。不推荐作为用户表的业务主键。3.2 ROWID (Row Identifier)定义与特性ROWID是KingbaseES特有的逻辑行标识符它是一个伪列为每行提供一个唯一的、单调递增的标识。ROWID的值是64进制字符串表示内部结构包含事务信息但它并非物理地址。存储ROWID不直接存储在表中但其逻辑存在需要内部机制维护实际存储占用4-18字节。唯一性与可靠性在KingbaseES中ROWID是唯一的并且默认会为其创建唯一B-tree索引保证了其唯一性和查询效率。其单调递增的特性在某些场景下有优势。主要用途提供了一种高效的行访问机制尤其适用于需要快速定位和操作单行数据的场景。可以作为一种内部的、高效的行引用方式但由于其伪列特性不适合作为业务主键。3.3 自增主键 (SERIAL/BIGSERIAL)定义与特性SERIAL和BIGSERIAL是KingbaseES提供的一种方便创建自增整数列的伪类型它们实际上是INTEGER和BIGINT类型并自动关联一个序列sequence对象确保插入新行时自动生成唯一的、递增的值。存储作为普通列存储在表中占用4字节SERIAL或8字节BIGSERIAL。唯一性与可靠性由序列保证全局唯一性是业务主键的最佳选择。SERIAL支持20亿条记录BIGSERIAL支持更大的数据量。主要用途广泛用于用户表作为业务主键提供稳定、可靠、易于理解的行标识。3.4 机制对比总结为了方便大家对比我把这仨机制的主要特点整理成下面这个表格特性OID (Object Identifier)ROWID (Row Identifier)自增主键 (SERIAL/BIGSERIAL)类型4字节整数64进制字符串表示内部复合结构4-18字节4字节整数 (SERIAL) / 8字节整数 (BIGSERIAL)存储伪列如果启用则占用存储伪列逻辑存在内部机制维护普通列实际存储在表中唯一性系统表全局唯一用户表局部唯一可能重复逻辑唯一默认有唯一索引保证全局唯一由序列保证可见性伪列需显式查询伪列需显式查询普通列直接可见可操作性不可直接修改不可直接修改可作为普通列操作但通常不建议手动修改自增值优先级低于ROWID当GUC参数冲突时高于OID当GUC参数冲突时独立于OID和ROWID推荐用途系统内部管理元数据查询高效行访问内部行引用用户表业务主键提供稳定可靠的行标识性能查找效率一般重复风险需额外索引默认有唯一B-tree索引查找效率高查找效率高通常作为聚簇索引或主键索引的一部分3.5 什么时候该选哪种机制选自增主键SERIAL/BIGSERIAL首选方案所有用户业务表我都强烈建议用自增主键来当行的唯一标识。它给咱们的保证最稳定、最靠谱而且管理和理解起来也简单。数据量考量得根据你估计的数据量来选是用SERIAL还是BIGSERIAL别等到数据溢出了才后悔。选ROWID特定场景优化当你需要一种高效、内部的行引用机制又不想让它掺和到业务逻辑里头去的时候可以考虑用ROWID。比如说某些内部工具或者临时查询需要快速找到并操作某一行用它就挺合适。性能敏感ROWID天生就带着唯一索引在那些需要通过行标识符快速查找的场景里它可能比那些没索引的普通列要快不少。兼容性需求如果你的应用是从别的数据库系统迁移过来的而且原来的应用依赖类似的行标识符概念那ROWID可能能提供更好的兼容性。别用OID当用户表的主键不推荐虽然能给用户表启用OID但因为它“各自为政”的特性、可能重复的风险还有不如自增主键那么靠谱的唯一性我不建议把它拿来当用户表的业务主键。它的主要价值还是在系统元数据管理那块儿。把这三种行标识机制的特点和适用范围搞明白了咱们开发者就能根据具体的业务需求和性能考虑在KingbaseES里做出聪明的选择从而搭出既高效又稳当的数据库应用。4. 元数据访问与系统表解析KingbaseES作为一款关系型数据库它内部维护着一大堆元数据专门用来描述数据库对象的结构、属性和它们之间的关系。这些元数据都存放在系统表里头而OID和regclass类型在咱们访问和解析这些元数据的时候可是起着关键作用的。4.1 深入理解系统表KingbaseES的系统表是数据库的“数据字典”记录了所有数据库对象的详细信息。以下是一些与对象标识符和元数据查询密切相关的系统表sys_class存储了所有表、索引、视图等关系对象的元数据。每个关系对象在sys_class中都有一条记录其oid列就是该对象的唯一标识符。sys_attribute存储了所有列属性的元数据。每条记录描述了一个表的某个列通过attrelid关联关系OID字段与sys_class中的对象关联。sys_type存储了所有数据类型的元数据。sys_proc存储了所有函数和存储过程的元数据。4.2 利用OID和regclass进行元数据查询regclass类型是KingbaseES提供的一种便捷机制它允许用户通过对象的名称来引用其OID从而简化了对系统表的查询。示例查询表的OID要获取一个表的OID最直接的方式是查询sys_class表SELECToidFROMsys_classWHERErelnameteachers;使用regclass类型转换可以更简洁地实现相同目的test# SELECT teachers::regclass;虽然直接输出的是表名但其内部表示就是该表的OID。在需要OID作为参数的查询中这种转换非常有用。示例查询表的列信息假设我们需要查询teachers表的所有列的详细信息包括列名、数据类型OID、长度、列号等。传统方式需要子查询或JOINSELECTattrelid,attname,atttypid,attlen,attnum,attnotnullFROMsys_attributeWHEREattrelid(SELECToidFROMsys_classWHERErelnameteachers);使用regclass简化查询SELECTattname,atttypid,attlen,attnum,attnotnullFROMsys_attributeWHEREattrelidteachers::regclass;这里的teachers::regclass实际上等同于SELECT oid FROM sys_class WHERE relnameteachers它返回了teachers表的OID从而实现了更简洁的元数据查询。示例查询数据类型信息类似地我们可以查询特定数据类型的OID或名称-- 查询integer类型的OIDSELECTinteger::regtype;-- 查询OID为1700的数据类型名称SELECT1700::regtype;4.3 元数据访问的意义数据库管理数据库管理员可以利用这些系统表和OID/regclass机制来监控数据库状态、诊断问题、管理权限和优化性能。应用开发开发者可以编写动态SQL或工具根据数据库的元数据自动调整应用行为例如生成ORM映射、数据迁移脚本或报表。审计与合规通过查询系统表可以获取对象的创建时间、修改历史、所有者等信息有助于满足审计和合规性要求。所以说OID和regclass类型是KingbaseES里访问和解析元数据的两把“利器”。它们给咱们提供了一种既高效又灵活的方法来跟数据库的内部结构打交道这对于咱们深入理解、有效管理KingbaseES数据库来说可是至关重要的。5. 兼容性与参数治理GUC参数冲突KingbaseES通过GUCGrand Unified Configuration参数给了咱们很灵活的配置选项让咱们能根据具体需求来调整数据库的行为。在处理行标识符这方面default_with_oids和default_with_rowid是两个挺关键的GUC参数它们管着新创建的表是不是默认带上OID或者ROWID。搞明白这些参数是怎么交互的、冲突了怎么解决对于数据库管理员和开发者来说要想把参数治理好这可是很重要的。5.1 行标识符相关的GUC参数default_with_oids作用当此参数设置为true时所有新创建的表将默认包含一个OID伪列。默认值通常为false。影响启用后用户表将拥有OID但如前所述其局部性和潜在重复风险使其不适合作为业务主键。default_with_rowid作用当此参数设置为true时所有新创建的表将默认包含一个ROWID伪列。默认值通常为false。影响启用后用户表将拥有ROWID并自动创建唯一B-tree索引提供高效的行访问能力。5.2 GUC参数冲突解决机制KingbaseES在处理default_with_oids和default_with_rowid这两个参数的冲突时遵循明确的优先级规则ROWID参数优先级高于OID参数。这意味着如果两个参数都被设置为trueKingbaseES会优先为新创建的表启用ROWID而忽略default_with_oids的设置。示例参数冲突时的行为-- 检查当前参数设置showdefault_with_oids;showdefault_with_rowid;-- 在两个参数都为on的情况下创建表createtablett_conflict(idint);insertintott_conflictvalues(10);-- 查询ROWID成功selectrowid,idfromtt_conflict;-- 查询OID失败selectoid,idfromtt_conflict;从上述示例可以看出尽管default_with_oids为on但由于default_with_rowid也为on新创建的表tt11会默认带有ROWID而不会带有OID这表明ROWID的优先级更高。显式WITH ROWID与GUC参数的交互当default_with_rowid为false且default_with_oids为true时如果尝试使用CREATE TABLE ... WITH ROWID语句KingbaseES会报错。这是因为在当前GUC参数配置下系统默认会为表创建OID而用户又显式要求创建ROWID这与GUC参数的优先级规则相悖。示例显式WITH ROWID与GUC参数的冲突set default_with_rowid to false; set default_with_oids to true; create table tt_explicit_rowid(id int) with rowid;这个错误信息明确指出在default_with_rowid为false且default_with_oids为true的情况下不能显式地创建带有ROWID的表。5.3 参数配置的最佳实践为了避免不必要的冲突和混淆建议在KingbaseES中进行参数配置时遵循以下最佳实践明确需求在决定是否启用default_with_oids或default_with_rowid之前应明确应用程序对行标识符的需求。如果需要高效的内部行引用机制并且接受其伪列特性可以考虑启用default_with_rowid。如果仅依赖系统内部的OID进行元数据管理且不希望用户表默认带有额外的标识符则保持default_with_oids为false。避免同时启用鉴于default_with_rowid的优先级通常不建议同时将default_with_oids和default_with_rowid都设置为true以避免潜在的混淆和不确定性。优先使用自增主键对于用户业务表始终优先使用SERIAL或BIGSERIAL作为主键而不是依赖OID或ROWID。自增主键提供了最可靠的唯一性保证和最佳的业务语义。表级控制如果只需要为少数特定表启用ROWID而不是全局启用则应将default_with_rowid保持为false并在创建这些表时显式使用WITH ROWID子句。文档记录对于生产环境中的GUC参数配置应进行详细的文档记录包括每个参数的设置原因和预期效果以便于后续的维护和故障排查。通过合理的参数治理可以确保KingbaseES数据库在行标识符方面能够满足应用程序的需求同时保持数据库的稳定性和可维护性。总结咱们今天把KingbaseES里头的OID和ROWID这俩行标识符机制聊了个透能看出来它们各有各的侧重点适合用在不同的地方。OID作为KingbaseES内部的对象标识符在系统元数据管理这块儿可是个关键角色它保证了数据库内部对象的一致性和可追溯性。不过对于咱们平时用的业务表来说因为它“各自为政”的特性和可能重复的风险一般不建议直接拿它当主键。但话说回来regclass类型倒是给咱们提供了一种非常方便的查询和管理数据库元数据的方法。ROWID呢是KingbaseES专门提供的一种高效的逻辑行标识符。它单调递增的特性加上默认就有的唯一索引让它在需要快速定位和操作单行数据的时候特别有用。当然啦ROWID和OID在GUC参数配置上谁先谁后的问题也提醒咱们在配数据库的时候得多留个心眼别踩了不必要的“坑”。至于咱们最常用的自增主键SERIAL/BIGSERIAL那依然是业务表主键的不二之选。它给咱们的保证最稳定、最可靠也最符合咱们对业务主键的那种直观理解。总的来说把这些行标识符的底层实现、特点和适用范围吃透了对用KingbaseES的伙计们来说特别重要。这不仅能帮咱们更高效地管理和优化数据库还能在搞应用设计的时候根据实际需求选出最合适的行标识策略从而搭出更结实、跑得更快的数据库应用。在KingbaseES的实践里把这些技术特性灵活运用起来可是提升数据库整体效能的关键。