数据是企业的核心资产，而数据库则是数据的载体。作为DBA，我们常将备份视为“最后一道防线”，但事实上，许多企业的备份策略仅停留在“形式化”——按时执行却从未验证过可用性。这种“假性安全”远比无备份更危险：当灾难发生时，才发现备份文件损坏、日志缺失或恢复流程失效，最终导致数据永久丢失。本文将从备份类型、工具选择、恢复演练到策略设计，系统梳理MySQL与Oracle的备份恢复最佳实践，助你构建真正可靠的容灾体系。  一、备份类型详解：按需选择，拒绝盲从数据库备份并非越频繁越好，关键在于匹配业务需求与资源成本。以下是三种主流备份类型的对比分析：  1. 全量备份     - 定义：完整复制数据库某一时刻的所有数据。     - 优点：结构简单，恢复速度快，适合小型数据库或低峰期操作。     - 缺点：占用存储空间大，耗时较长，不适合高频次执行。     - 适用场景：初次迁移、季度归档、长期存档。  2. 增量备份   - 定义：仅备份自上次备份（无论全量或增量）以来变化的数据。     - 优点：节省存储空间和时间，适合高频次备份。     - 缺点：恢复时需按顺序应用历次增量备份，复杂度较高。     - 适用场景：每日例行备份、交易型系统的日常维护。  3. 差异备份    - 定义：备份自上次全量备份后所有变化的数据。     - 优点：介于全量与增量之间，恢复速度优于增量备份。     - 缺点：随着时间推移，备份体量逐渐增大。     - 适用场景：中等规模数据库的周期性补充备份。  选型原则：若业务对恢复时间要求极高（RTO<1小时），优先采用“全量+增量”组合；若存储成本敏感且可容忍稍长恢复时间，可尝试“全量+差异”模式。二、备份工具实战：MySQL与Oracle的差异打法  MySQL篇：逻辑导出 vs 物理拷贝 1. `mysqldump`——逻辑导出工具     - 特点：生成SQL脚本，兼容性强，支持跨版本迁移。     - 典型命令：     - 局限性：大型数据库备份速度慢，锁表时间长，不适合高并发场景。   2. `xtrabackup`——物理热备工具     - 特点：直接拷贝数据文件，无需锁表，支持InnoDB存储引擎的崩溃恢复。     - 典型命令：      - 优势：备份速度快，对在线业务影响小，适合TB级数据库。   Oracle篇：RMAN——企业级备份利器1. 基础配置    - 修改`init.ora`文件启用归档模式：`log_archive_dest_1='location=/arch'`     - 创建恢复目录并连接RMAN：`rman target /`  2. 常用备份脚本    - 核心功能：支持块级压缩、加密备份、异地容灾，可通过`validate backupset`命令校验备份完整性。 三、恢复演练：检验备份有效性的唯一标准  “能恢复的备份才是好备份”。以下以“误删表”场景为例，演示完整恢复流程：  MySQL恢复示例  1. 故障现象：某业务表`orders`被`DROP TABLE`误操作。  2. 恢复步骤：     - 步骤1：定位最新全量备份文件（如`full_20240101.sql`）。     - 步骤2：执行SQL脚本导入全量数据：`mysql -u root -p dbname < full_20240101.sql`。     - 步骤3：逐条应用后续增量备份（按时间顺序）：`mysql -u root -p dbname < incr_20240102.sql`。     - 验证：通过`CHECKSUM TABLE orders`对比原始数据一致性。  Oracle恢复示例 1. 故障现象：用户表空间中的`EMPLOYEE`表被删除。  2. 恢复步骤：     - 步骤1：启动RMAN并连接到目标实例：`rman target /`。     - 步骤2：还原到最新备份时间点：`RESTORE DATABASE UNTIL TIME 'SYSDATE-1';`。     - 步骤3：重放归档日志补足后续变更：`RECOVER DATABASE USING ARCHIVELOG;`。    - 验证：通过`DBMS_STATS.GENERATE_SCHEMA_STATISTICS()`刷新统计信息。  关键提示：恢复前务必在测试环境预演，避免生产环境二次伤害！四、备份策略建议：经典“6+1”滚动方案  推荐采用“每周日全备+每日增备”的经典策略，并根据业务波动灵活调整：    注意事项：  - 备份文件命名需包含时间戳（如`full_20240101_1500.sql`），便于追溯。  - 定期清理过期备份（建议保留最近4周的增量备份+1份全量）。  - 异地备份需满足“两地三中心”原则，防止区域性灾害。五、总结：备份的本质是“可恢复性”许多企业陷入“备份越多越好”的误区，却忽视了最核心的问题——这些备份能否在关键时刻派上用场？定期进行恢复演练，验证备份文件的完整性、工具链的可靠性以及团队的操作熟练度，才是衡量备份策略成功与否的唯一标准。记住：没有经过实战检验的备份，只是一串无用的数字。从今天开始，重新审视你的备份方案，让数据真正“活”起来！

openGemini技术洞察 一   关于openGemini          openGemini是一款面向IoT和Devops场景垂直优化的分布式时序数据库，提供单机和分布式版本，具备卓越的读写性能和高效的数据分析能力，支持主流开发语言和多形态部署（如云、Docker、物理机等）。openGemini主要聚焦于海量时序数据的存储和分析，通过技术创新，降低海量时序数据存储成本，简化业务系统架构，提升时序数据存储和分析效率。         openGemini背靠华为云丰富的IoT和Devops场景，经受住了海量时序数据管理的实战考验。自开源以来，不断收到来自社区用户的正向反馈，已累积在60+企业测试和生成落地使用。         openGemini具有五大核心特性：1.高性能：支持亿级时间线和PB级时序数据管理，每秒千万级数据写入和毫秒级查询响应，相比InfluxDB，简单查询性能提升2-5倍，复杂查询性能提升60倍2.分布式：采用MPP大规模并行处理分层架构，由ts-sql、ts-meta、ts-store三个组件组成，各组件可独立扩展，支持100+节点的大规模集群部署3.存储分析一体化：内置AI数据分析平台，提供了对时序数据的实时异常检测能力，实现了数据从存储到分析完整的闭环管理4.运维成本低：提供260+项系统运行监控指标，快速提升问题解决的效率。部署过程中不依赖任何第三方组件和应用，极大降低了运维难度和成本5.高数据压缩率：采用列式存储方式，提供高效数据压缩算法，相同数据量下存储成本仅有关系型数据库的1/20，NoSQL的1/10 二   openGemini使用场景 openGemini 是一个开源的时序数据库，专注于高性能的时序数据存储、查询和分析。它适用于多种需要处理大量时间序列数据的场景，尤其在物联网（IoT）、监控、金融、日志分析等领域表现突出。以下是 openGemini 的主要使用场景：1. 物联网（IoT）与工业互联网设备监控：实时采集和存储传感器数据（如温度、湿度、压力等），并支持快速查询和分析。预测性维护：通过历史数据趋势分析，预测设备故障或异常。边缘计算：与边缘设备结合，实现本地化数据处理和实时响应。2. IT 基础设施与运维监控服务器/容器监控：存储 CPU、内存、磁盘、网络等指标数据，支持 Prometheus 兼容的查询。应用性能管理（APM）：追踪微服务或分布式系统的性能指标（如延迟、错误率）。告警与分析：基于时序数据触发告警，并快速定位问题根源。3. 金融与交易数据分析高频交易：存储和分析秒级/毫秒级的交易数据，支持实时风控。行情数据存储：记录股票、加密货币等的价格变动历史。用户行为分析：分析交易行为的时间序列模式（如登录频率、操作习惯）。4. 日志管理与分析集中式日志存储：替代 Elasticsearch 的部分场景，存储时间戳日志（如 Nginx、Kubernetes 日志）。日志实时分析：通过 SQL-like 查询快速检索日志，或聚合分析错误趋势。5. 能源与智慧城市智能电表/水表数据：存储居民或企业的能源消耗数据，支持分时计费和大规模聚合。环境监测：分析空气质量、噪声等环境传感器的时序数据。6. 车联网与自动驾驶车辆遥测数据：记录车辆行驶中的速度、油耗、GPS 位置等数据。驾驶行为分析：通过时间序列数据优化路线或检测危险驾驶。7. 其他场景科研实验数据：存储实验室设备生成的时间序列结果（如生物、化学实验）。游戏数据分析：记录玩家在线行为、道具交易等时序事件。openGemini 的核心优势高性能：针对时序数据优化，支持高吞吐写入和低延迟查询。水平扩展：分布式架构，可轻松扩展集群规模。兼容性：支持 InfluxDB Line Protocol、PromQL 等协议，降低迁移成本。成本效益：开源方案，相比商业时序数据库（如 InfluxDB Enterprise）更经济。典型用户案例某智能制造企业：用 openGemini 存储万台设备的传感器数据，实现实时监控。某云服务商：替代 Elasticsearch 存储日志，降低 50% 存储成本。某金融公司：分析高频交易数据，延迟控制在毫秒级。 三   openGemini的安装与使用 通过docker安装openGemini：docker run -d --name opengemini opengeminidb/opengemini-server:latest安装日志：C:\Windows\System32>docker run -d --name opengemini opengeminidb/opengemini-server:latestUnable to find image 'opengeminidb/opengemini-server:latest' locallylatest: Pulling from opengeminidb/opengemini-server0de4ca3c6b94: Pull complete0e0c0faae025: Pull complete631a47dfb3a9: Pull completed9b4a4d929b9: Pull complete9b244a79caed: Pull completeDigest: sha256:cf2db989234638460423bbd20af64c743684f48449227302c3868e0a8872079bStatus: Downloaded newer image for opengeminidb/opengemini-server:latest2e31cad3116dce374b374207aaff383464e09eb3a5aef2d839ff7a5298b8ae4e 使用openGemini cli 连接：docker exec -it opengemini ts-cli 创造数据库：create database db0 展示目前的数据库列表：show databases  使用数据库use db0 写数据insert cpu_load,host=server-01,region=west_cn value=75.3 查看表show measurements  查询数据select * from cpu_load docker run -p 8086:8086 58b26b87069a73291fd55addfa1f30780735f47e95199fe6d7699fed29281db2  日志信息：C:\Windows\System32>docker exec -it opengemini ts-cliopenGemini CLI  (rev-)Please use `quit`, `exit` or `Ctrl-D` to exit this program.> create database db0> show databasesname: databases+-----------+|   name    |+-----------+| _internal || db0       |+-----------+1 columns, 2 rows in set> use db0Using database: db0, retention policy: autogen> insert cpu_load,host=server-01,region=west_cn value=75.3> show measurementsname: measurements+----------+|   name   |+----------+| cpu_load |+----------+1 columns, 1 rows in set> select * from cpu_loadname: cpu_load+---------------------+-----------+---------+-------+|        time         |   host    | region  | value |+---------------------+-----------+---------+-------+| 1755072990101890304 | server-01 | west_cn |  75.3 |+---------------------+-----------+---------+-------+4 columns, 1 rows in set>  CLI写数据Line Protocol（行协议） 是InfluxDB提出的一种基于文本的数据格式，openGemini使用相同Line Protocol，用于将points 写入 openGemini。 > INSERT weather,location=us-midwest temperature=82 1465839830100400200> select * from weathername: weather+---------------------+------------+-------------+|        time         |  location  | temperature |+---------------------+------------+-------------+| 1465839830100400128 | us-midwest |          82 |+---------------------+------------+-------------+3 columns, 1 rows in set InfluxQL查询SELECT top("value", 1) FROM "weather" 日志：> SELECT top("value", 1) FROM "cpu_load"name: cpu_load+---------------------+------+|        time         | top  |+---------------------+------+| 1755072990101890304 | 75.3 |+---------------------+------+2 columns, 1 rows in set 过滤查询 INSERT weather,location=us-midwest1 temperature=82 1165839830100400200INSERT weather,location=us-midwest1 temperature=52 1165839830100400202INSERT weather,location=us-midwest1 temperature=12 1165839830100400201 > SELECT * FROM "weather" WHERE "temperature" > 50name: weather+---------------------+-------------+-------------+|        time         |  location   | temperature |+---------------------+-------------+-------------+| 1165839830100400128 | us-midwest1 |          82 || 1165839830100400128 | us-midwest1 |          52 |+---------------------+-------------+-------------+3 columns, 2 rows in set 四   总结openGemini通过开源协作推动时序数据库技术的普惠化，帮助各行业高效挖掘时序数据价值。openGemini针对物联网、监控等场景的海量时序数据（高写入吞吐、低查询延迟）优化，解决传统关系型数据库或通用 NoSQL 数据库的效率瓶颈。

1.  数据库分布键调整【分布键选取原则】   分布式表的分布策略有几种，其中主要是有复制分布、HASH分布、范围分布，其中对于Hash分区表，Hash分布表的分布列选取至关重要，需要满足以下原则：1、 列值应比较离散，以便数据能够均匀分布到各个DN。例如，考虑选择表的主键为分布列，如在人员信息表中选择身份证号码为分布列。2、 在满足第一条原则的情况下尽量不要选取存在常量filter的列。例如，表dwcjk相关的部分查询中出现dwcjk的列zqdh存在常量的约束(例如zqdh=’000001’)，那么就应当尽量不用zqdh做分布列。3、 在满足前两条原则的情况，考虑选择查询中的连接条件为分布列，以便Join任务能够下推到DN中执行，且减少DN之间的通信数据量。4、 对于Hash分表策略，如果分布列选择不当，可能导致数据倾斜，查询时出现部分DN的I/O短板，从而影响整体查询性能，不同DN的数据量相差5%以上即可视为倾斜，如果相差10%以上就必须要调整分布列。 业务表在分布式场景下，分布键如果不指定默认用第一列，对这边第一列大部分都是xxxxx字段，而这个字段的值都是9999，从而导致数据都分布在一个节点上。本次根据实际业务情况，调整了800张左右表的分布列，对于小表且改动比较少采用复制表方式，其他表是参照列值的散列情况及索引创建等按hash方式进行分布，调整后系统性能得到初步改善；【数据分布检查语句】select * from pgxc_get_table_skewness where schemaname=’xxxxx’ order by skewratio desc;若skewratio大于0.1，需要重点关注。2.  XLOGS分盘将XLOG日志文件目录单独放在一块nvme盘上，方式通过软链接方式实现，从而减轻数据盘压力，提高数据库整体IO能力。如：ln -s /data/dn_6001/pg_xlog  /data/cluster/data/dn/dn_6001/pg_xlog3.   数据库参数调整针对关键参数进行调整GaussDB参数参数说明推荐值默认值分类名称资源消耗内存max_process_memory设置一个数据库节点可用的最大物理内存(物理内存大小 - vm.min_free_kbytes)* 0.7 / (1 + 主节点个数)Cn:110GBDn:320GB视系统、部署情况而定shared_buffers设置GaussDB Kernel使用的共享内存大小；建议设置shared_buffers值为内存的40%以内，如果设置较大的shared_buffers需要同时增加checkpoint_segments的值，因为写入大量新增、修改数据需要消耗更多的时间周期Cn:4GBDn:160GB视系统、部署情况而定work_mem设置内部排序操作和Hash表在开始写入临时磁盘文件之前使用的内存大小。ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列连接、散列为基础的聚集、散列为基础的IN子查询处理中都要用到128MB视系统情况而定maintenance_work_mem设置在维护性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的内存。该参数的设置会影响VACUUM、VACUUM FULL、CLUSTER、CREATE INDEX的执行效率。建议设置此参数的值大于work_mem，可以改进清理和恢复数据库转储的速度1GB视系统情况而定max_prepared_transactions设置可以同时处于"预备"状态的事务的最大数目。增加此参数的值会使GaussDB Kernel比系统默认设置需要更多的System V共享内存　1200　内核资源消耗max_files_per_process设置每个服务器进程允许同时打开的最大文件数目。如果操作系统内核强制一个合理的数目，则不需要设置。1024 1024 最大连接数Max_connections数据库会话最大连接数18000根据实际情况而定  线程池开启enable_thread_pool控制是否使用线程池功能，一般都开启On on 控制线程池功能的详细属性thread_pool_attr设置线程池功能的详细属性。该参数分为3个部分：1) thread_num：线程池中的线程总数，取值范围是0~4096。其中0的含义是数据库根据系统CPU core的数量来自动配置线程池的线程数，如果参数值大于0，线程池中的线程数等于thread_num。2) group_num：线程池中的线程分组个数，取值范围是0~64。其中0的含义是数据库根据系统NUMA组的个数来自动配置线程池的线程分组个数，如果参数值大于 0，线程池中的线程组个数等于group_num。3) cpubind_info：线程池是否绑核的配置参数。Cn:2048,2,(nobind)Dn:4096,2,(nobind)根据实际情况设置4.  慢SQL调优4.1查询top SQL的语句：select n_calls,unique_sql_id,substr(query,1,50) as query,total_elapse_time/n_calls/1000 as avg_time,total_elapse_time/1000 as runtime from dbe_perf.statement where user_name='cbsprd' and n_calls>10 and avg_time>5 order by runtime desc;4.2慢SQL存在主要几种表现：1） 存在重分布（分布式数据库独有现象），即选择分布列不合理，导致数据在DN之间需要进行重分布，从而影响性能调整分布列前：在***_jyyxrz表存在重分布，这个表的分布为piljybss；而***_jykzhq的分布列为pljyzbsh，两个表关联存在重分布情况。优化方案：将***_jyyxrz的分布列也调整为pljyzbsh，且两表关联也是带这个条件的，其执行情况如下：优化结果：消除dn节点间数据重分布，时间从原来13ms提升至7ms。2） 未走索引，全表扫描从上图可以看出，若出现“seq scan on ……”即表示表未走索引，增加耗时。在***_jyyxrz_0704上增加索引后，如下图：优化结果：走上索引扫描，运行时间从361ms降为6.6ms3） 未使用最佳索引此问题出现在***_sfdjbu的索引上，kcgb_sfdjbu_idx10是创建一个（shoufdma,jiluztai,shouqibz,kehuzhao,sfkhuzhh,guiylius）复合索引，但该语句的where中sfkhuzhh字段上使用了or，故不能采用一个复合索引，由此创建两个索引新建索引字段如下：增加索引后，SQL语句改走这两个，时间从原来的95ms缩减到9.5ms4） SQL改写因分布式场景及gaussdb和oracle的SQL语法差异性，存储少数复杂SQL的改写，具体如下：改写前：改写后的SQL语句：将or exist改写为union all的方式，来减少数据的遍历，从而提升性能，时间从原来的89秒降低到82毫秒。5）加SQL PATCH：总之，单SQL优化是多方面的，是一个持续过程，直到满足性能要求为止。

分布式数据库表结构以id 为自增分布键 采用 hash 方式分布如何查看某个数据所在的存储位置 

分布式数据库无疑是数据库未来发展的一个重要趋势。随着大数据、云计算、物联网等技术的快速发展，数据量呈现出爆炸式的增长，传统的单体数据库在处理海量数据和高并发请求时显得力不从心。而分布式数据库通过将数据分散存储在多个节点上，并利用这些节点进行并行处理，可以有效地解决这些问题。分布式数据库的优势主要体现在以下几个方面：扩展性：分布式数据库能够方便地通过增加节点来扩展存储和计算能力，从而满足不断增长的数据和业务需求。高可用性：通过数据冗余和复制，分布式数据库可以实现高可用性和容错性，即使部分节点出现故障，也不会影响整个系统的正常运行。高性能：分布式数据库利用多个节点进行并行处理，可以显著提高查询和更新操作的性能，特别是在处理大数据量和高并发请求时表现尤为突出。此外，随着云计算的普及，越来越多的企业开始将业务部署到云端。分布式数据库与云计算的结合，可以为企业提供更加灵活、高效和安全的数据存储和计算服务。当然，分布式数据库也面临着一些挑战，如数据一致性、安全性、复杂性等问题。但随着技术的不断进步和成熟，这些问题也将逐渐得到解决。因此，可以预见，在未来，分布式数据库将在更多领域得到广泛应用，成为数据处理和存储的主流解决方案之一。

主要代码PGReplicationStream stream = pgConnection.getReplicationAPI() .replicationStream() .logical() .withSlotName("test_slot") .withSlotOption("include-xids", false) .withStatusInterval(2000, TimeUnit.SECONDS) .start();在调用 stream.read();方法的时候 报错 org.postgresql.util.PSQLException: FATAL: insufficient data left in messagestream.read() 在正常打印一部分数据 后才报错误，如图：求帮助 ，感谢。

dws里面看到协调节点的数据文件如何对应到master里面的数据文件呢。用pg_relation_filepath只能查到cn的路径

2023 年第三季度，Navicat 首次支持了华为云 GaussDB 主备版数据库。经过双方团队进一步的深化合作，Navicat 完成了 GaussDB 分布式的研发适配工作，赋能 GaussDB 全域数据库产品。GaussDB 数据库分为主备版和分布式版两种模式。主备版适用于数据量较小，且长期来看数据不会大幅度增长，但是对数据的可靠性，以及业务的可用性有一定诉求的场景。分布式版能够支撑较大的数据量，且提供了横向扩展的能力，可以通过扩容的方式提高实例的数据容量和并发能力。Navicat Premium 16.3.3 windows 版本已于近日正式发布。该版本新增了 GaussDB 分布式数据库的功能，同时也实现了与主备版模式一致的功能，不仅提供可视化操作能力，如：数据增删改查、SQL 或脚本处理、函数、数据生成等，还蕴含了丰富的高级功能：协同合作、数据迁移、数据传输、结构同步、数据同步、模型、图表、自动运行、角色权限管理、服务器监控等。此次合作，除了满足了 GaussDB 不同用户与场景的多样化需求，也促进了双方在数据库领域的成长和发展。未来，双方会保持紧密合作，共同研发更符合市场需求的产品。华为云 GaussDB华为在数据库领域战略投入20多年，围绕客户全场景诉求打造了 GaussDB 分布式数据库。GaussDB是当前国内唯一做到全栈软硬协同自主创新的数据库产品，有高度的语法兼容性，可以提供一站式整体迁移解决方案，原生分布式架构大幅提升了系统的可用性，构建了高可用、高安全、高性能、高弹性、高智能、易部署、易迁移“五高两易”的核心技术竞争力。目前，GaussDB 已在华为内部IT系统和多个行业核心业务系统得到应用。未来，GaussDB 将持续深耕金融政企场景，通过全面创新，成为金融政企客户以及其他关键基础设施行业客户的更优选择。NavicatPremiumSoft 公司成立于1999年，创立了 Navicat 品牌和系列产品，总部位于中国香港。公司专注于数据库工具配套技术的研发与技术创新，以产品力和客户需求为导向不断提升工具的可靠性、便捷性、稳定性和安全性。Navicat致力于帮助全球用户（数据库相关工作者、应用开发者以及数据分析师等）简化管理和维护数据库。目前，超过五成的《财富》世界500强企业每天都会使用 Navicat。此外，Navicat 被广泛应用在各行各业，也受到金融客户的信赖。目前，浦发银行、农商银行、农业银行、中国银联和泰康保险都选择了 Navicat。

pg_default_acl表原始数据select * from pg_default_acl;pg_default_acl表简单处理sqlSELECT pg_catalog.pg_get_userbyid(d.defaclrole) AS "Granter", n.nspname AS "Schema", CASE d.defaclobjtype WHEN 'r' THEN 'table' WHEN 'S' THEN 'sequence' WHEN 'f' THEN 'function' WHEN 'T' THEN 'type' END AS "Type", pg_catalog.array_to_string(d.defaclacl, E', ') AS "Access privileges" FROM pg_catalog.pg_default_acl d LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.defaclnamespace ORDER BY 1, 2, 3;1、先建立一个权限的映射表create table public.ysw ( prototype varchar(1), aim varchar(10) ); insert into ysw values('r','select'); insert into ysw values('a','insert');2、创建一个函数转化格式，比如将权限ra转化为select,insert形式create or replace function fun_ysw(varchar) returns varchar as $$ declare re varchar :=''; tmp varchar := ''; fr varchar :=''; i int := 1; length int := char_length($1); begin while i<=length loop select substring($1,i,1) into fr; select aim into tmp from ysw where prototype = fr; re :=concat(re,tmp); if i<length then re :=concat(re,','); end if; i :=i+1; end loop; return re; end; $$ LANGUAGE plpgsql;3、最终查询sql示例模板：alter default privileges for user 原始 in schema 模式 grant 拼接权限 on 类型 to 用户可能多个;查询sqlSELECT pg_catalog.pg_get_userbyid(d.defaclrole) AS "granter", n.nspname AS "schema", CASE d.defaclobjtype WHEN 'r' THEN 'tables' WHEN 'S' THEN 'sequences' WHEN 'f' THEN 'functions' WHEN 'T' THEN 'types' END AS "Type", d.defaclacl, fun_ysw(to_char(regexp_substr(d.defaclacl[1]::text, '(?<=\=).*?(?=\/)'))) as right, rtrim(regexp_replace(concat(pg_catalog.array_to_string(d.defaclacl, E','),','), '\=.*?(?=\,)','','g'),',') as usernames FROM pg_catalog.pg_default_acl d LEFT JOIN pg_catalog.pg_namespace n ON n.oid = d.defaclnamespace ORDER BY 1, 2, 3;最后可以按需求拼接，，要根据数据状况进行适当修改