Aurora PostgreSQL 12.6如何通过pg_cron定时执行REINDEX CONCURRENTLY重建索引

报错根因 #

PostgreSQL 中 REINDEX CONCURRENTLY 要求运行在独立的事务上下文，不能嵌套在函数、存储过程或事务块内部，这是版本原生的设计约束，12.6 版本没有直接绕过的方法。

可行实现方案 #

方案1：通过 pg_cron 批量调度独立的 REINDEX 任务 #

如果不想引入外部工具，可以直接基于 pg_cron 拆分任务执行：

1. 先执行以下查询生成所有业务表的索引重建语句：

SELECT format('REINDEX CONCURRENTLY TABLE %I.%I;', schemaname, tablename) 
FROM pg_tables 
WHERE schemaname NOT IN ('pg_catalog', 'information_schema', 'pg_toast');

2. 将查询返回的所有语句，每条作为独立任务配置到 pg_cron 中，避免多条语句包裹在同一事务内。比如配置每天凌晨 2 点执行的任务示例：

-- 单表索引重建调度示例
SELECT cron.schedule('reindex-table-public-users', '0 2 * * *', 'REINDEX CONCURRENTLY TABLE public.users;');

方案2：使用外部调度工具执行 #

如果表数量较多，不想配置大量 pg_cron 任务，可以用外部定时调度工具（如 Linux crontab、企业内部调度平台等）连接数据库执行：

1. 编写 SQL 脚本文件 reindex_all.sql，内容为上一步生成的所有 REINDEX CONCURRENTLY 语句，每条语句单独一行。
2. 配置外部调度工具定时执行 psql 命令调用脚本：

psql -h <Aurora实例地址> -U <连接用户名> -d <目标数据库名> -f reindex_all.sql

这种方式下每条 REINDEX CONCURRENTLY 会作为独立事务执行，不会触发事务嵌套报错，也方便统一维护调整。

方案3：非生产环境简化方案 #

如果是测试环境，或者业务可以接受短时间锁表，可以直接去掉 CONCURRENTLY 关键字，使用普通 REINDEX 命令，这种方式可以正常在自定义函数内执行，适合对可用性要求不高的场景。

注意事项 #

• REINDEX CONCURRENTLY 执行期间会产生额外的磁盘 IO 和存储占用，建议选择业务低峰期执行
• 重建前建议先统计索引膨胀率，仅重建膨胀率超过 30% 的索引即可，不需要频繁全量重建，减少不必要的资源消耗

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