YugabyteDB并发DDL场景下视图不存在问题求助

问题原因解析 #

1. Colocated数据库的DDL事务性：你使用的是COLOCATED模式创建的数据库，YugabyteDB 2.x版本中，colocated数据库的元数据（包括视图、表结构等）存储在共享的colocated表中，这类元数据操作（如CREATE OR REPLACE VIEW）是事务性的——只有当包含DDL的外层事务提交后，DDL的效果才会对其他事务可见。这和非colocated数据库的DDL行为（立即生效、非事务性）完全不同，也是你之前误解的核心点。

2. 事务隔离级别的限制：你的4个线程各自开启独立事务，调用创建视图函数后，在同一个事务内尝试操作视图或重试查询视图。由于YugabyteDB默认的Read Committed隔离级别，事务只能看到自己启动前已提交的数据，以及自身事务内的修改。即使第一个线程提交事务创建了视图，其他三个线程的当前事务快照不会更新，所以直到它们的事务结束，都无法看到这个新创建的视图。

解决方案 #

方案1：使用自治事务执行DDL #

将视图创建操作放在自治事务中执行，让DDL操作脱离外层事务，立即提交生效，这样其他线程可以马上看到视图。修改你的create_view_on_table_if_needed()函数如下：

CREATE OR REPLACE FUNCTION create_view_on_table_if_needed(p_view_name text, p_table_name text)
RETURNS void AS $$
BEGIN
    -- 开启自治事务，独立于外层事务
    PRAGMA autonomous_transaction;
    -- 执行视图创建逻辑
    EXECUTE format('CREATE OR REPLACE VIEW %I AS SELECT * FROM %I', p_view_name, p_table_name);
    -- 提交自治事务
    COMMIT;
END;
$$ LANGUAGE plpgsql;

方案2：调整事务边界 #

如果无法使用自治事务，可以调整线程的事务逻辑：

• 先单独执行视图创建操作并提交事务
• 再开启新事务执行对视图的操作
  这种方式需要拆分原有的事务流程，确保DDL操作在独立事务中完成并提交。

方案3：重置事务快照 #

如果不想修改函数，也可以在每个线程调用创建函数后，主动结束当前事务，重新建立连接后再查询视图是否存在，但这种方式对业务代码侵入性较高。

额外说明 #

• 对于非colocated的表，其元数据操作依然是非事务性的，但你的数据库整体是colocated模式，视图属于数据库级元数据，所以依然遵循colocated的事务规则。
• 自治事务在YugabyteDB 2.10及以上版本支持，你的2.14.2.0版本完全兼容。

内容的提问来源于stack exchange，提问作者dh YB