%ROWTYPE 变量必须基于真实存在的表或视图，不能虚构；支持 SELECT * INTO 单行赋值，但需处理 NO_DATA_FOUND 和 TOO_MANY_ROWS 异常；不继承约束，不兼容不同表结构，且自动适配表变更。
用 %ROWTYPE 声明变量时，必须基于已存在的表或视图
oracle 不允许在没有实际对象的前提下“虚构”一个结构来用 %rowtype。比如你不能写 declare r my_fake_table%rowtype; 然后指望它自动生效——my_fake_table 必须是当前 schema 下真实存在的表或视图（且调用者有 select 权限）。
常见错误现象：PLS-00201: identifier 'XXX' must be declared 或 ORA-00942: table or view does not exist，往往是因为拼错表名、大小写不匹配（尤其建表时加了双引号）、或者跨 schema 没带前缀。
- 使用场景：快速声明与查询结果结构一致的变量，比如
SELECT * INTO r FROM employees WHERE ROWNUM = 1; - 如果表字段含
NOT NULL约束，%ROWTYPE变量对应字段仍可赋NULL—— 它只映射结构，不继承约束语义 - 视图也支持
%ROWTYPE，但注意：视图定义若含表达式列（如salary * 12 AS annual_salary），该列在%ROWTYPE中类型为NUMBER，但无法直接SELECT ... INTO赋值给它（会报ORA-06548: no more rows to fetch类似错误），因为表达式列不可更新、也不参与行绑定
%ROWTYPE 和 RECORD 类型的关键区别在哪
%ROWTYPE 是 Oracle 内置的快捷语法，本质是编译期绑定到具体对象；而 RECORD 是用户自定义复合类型，需显式声明字段和类型，灵活性高但维护成本也高。
容易踩的坑：有人以为 emp_rec employees%ROWTYPE 和 emp_rec RECORD (emp_id NUMBER, name VARCHAR2(100)) 行为一致，其实不然：
-
%ROWTYPE变量可直接用于SELECT ... INTO，只要列数、顺序、类型兼容；RECORD必须严格按字段顺序一一对应，否则报PLS-00302: component 'XXX' must be declared - 表结构变更后，
%ROWTYPE自动适配（重编译 PL/SQL 即可），RECORD不会自动同步，容易引发运行时报错或静默截断 - 性能上无差异，但
%ROWTYPE编译检查更早，能提前暴露字段缺失问题
嵌套块里用 %ROWTYPE 需注意作用域和重定义冲突
在子块中重新声明同名的 %ROWTYPE 变量，不会覆盖外层变量，而是形成遮蔽（shadowing）。这本身合法，但容易导致逻辑混乱。
典型误用场景：外层声明 r emp%ROWTYPE，内层又写 r dept%ROWTYPE，接着在内层用 r.empno 就会报错 —— 因为此时 r 是 dept%ROWTYPE，根本没 empno 字段。
- 建议给变量起有意义的名字，比如
emp_row、dept_row，避免纯用r - 不要依赖“同名即同结构”的假设；不同表的
%ROWTYPE类型互不兼容，哪怕字段名和类型完全一样，也不能互相赋值 - 如果真要复用结构，考虑用
CREATE TYPE ... AS OBJECT定义命名对象类型，再声明变量为该类型，比反复用%ROWTYPE更可控
SELECT * INTO 配合 %ROWTYPE 时，必须确保返回且仅返回一行
这是最常被忽略的执行期限制：%ROWTYPE 变量只能接收单行结果。一旦 SELECT * INTO 查出 0 行，抛 NO_DATA_FOUND；查出 2 行及以上，抛 TOO_MANY_ROWS。
很多人以为“声明对了结构就万事大吉”，结果上线后因数据变化突然崩掉。
- 安全做法：总是用
BEGIN ... EXCEPTION WHEN NO_DATA_FOUND THEN ... WHEN TOO_MANY_ROWS THEN ... END;包裹 - 如果业务本意就是取最多一行，改用游标 +
FETCH ... BULK COLLECT INTO更稳妥，哪怕只取一条也推荐这样写 -
SELECT * INTO中的*会按表定义顺序展开所有列，若表新增字段，%ROWTYPE变量自动容纳，但旧代码若依赖字段位置（比如r.col1 := ...），可能因新增字段打乱顺序而失效
复杂点在于：它看着像语法糖，实则把表结构、执行逻辑、异常路径全耦合在一起。稍不留神，DDL 变更或数据波动就会穿透到运行时。
