必须显式限定schema，否则多schema同名表会导致“table name is ambiguous”或“relation does not exist”错误；search_path仅提供默认查找顺序，无法解决命名冲突，精准访问须用schema.table形式明确作用域。
因为不加Schema限定时，数据库无法确定你要查的是哪个同名表——尤其当多个Schema下存在相同表名，或查询中多次引用同一表名（比如自连接、子查询）时，table name is ambiguous 或 relation does not exist 这类报错就必然出现。
多Schema同名表导致的“找不到表”错误
PostgreSQL、GaussDB 等支持多Schema的数据库中，users 可能同时存在于 public、sales、archive 三个 Schema 下。如果你只写 SELECT * FROM users;：
- 数据库会按
search_path顺序查找，一旦路径里有多个同名表，或目标表不在路径中，就会报relation "users" does not exist - 即使查到了，也可能不是你预期的那个 Schema 下的
users，导致数据错乱 - 在函数、存储过程里执行时，
search_path可能被重置，行为更不可控
GaussDB 中 queryblock + schema 双重限定才能精准命中 Hint 目标
GaussDB 的 Hint（如 tablescan、indexscan）必须明确指向某个具体表实例，否则直接报 TableScan(t1), relation name "t1" is ambiguous：
- 子查询里也叫
t1？得用t1@sel$2指定 queryblock - 两个 Schema 都有
t1？得用sales.t1或archive.t1显式限定 - 两者叠加：写成
sales.t1@sel$2才算完全无歧义 - 别名优先：如果
t1在子查询里起了别名tt1，Hint 必须写tt1@sel$2，不能用原名
MySQL 虽不强制 Schema，但跨库操作时全限定名是唯一安全方案
MySQL 的 database.table 形式本质就是 Schema 限定（database = schema）：
- 存储过程中执行
UPDATE users SET ...，若没指定库名，可能误改当前连接默认库下的表 - 多租户场景下，
tenant_a.users和tenant_b.users必须靠前缀区分 - 触发器或事件中引用表，不加库名极易因上下文切换导致操作错表
-
JOIN tenant_a.orders o ON o.user_id = tenant_b.users.id这种跨库关联，缺一不可
真正容易被忽略的点在于：Schema 限定不是“锦上添花”，而是**作用域声明**——它和表别名一样，定义了名字在哪一层上下文中有效。一旦涉及多层嵌套、跨库/跨Schema、Hint 控制执行计划，漏掉限定就等于把解析权交给数据库猜，而猜错的结果从来不是报错那么简单，可能是静默错查。
