3.1 OLTP 读写混合（oltp_read_write，30s）#

3.2 只读（oltp_read_only，25s）#

3.3 只写 / 插入型（oltp_write_only，25s）#

（PG 系只写在插入随机主键时的少量 duplicate-key 报错为 sysbench 正常行为，非故障。）

3.4 结果怎么读#

1. PolarDB-PG ≈ 原生 PostgreSQL（几乎打平） —— 三种负载下差距都在误差量级内（读写混合 1086 vs 1086，只读 1895 vs 1840，只写 4413 vs 4877）。这恰恰验证了它的本质：单节点、本地存储模式下，PolarDB-PG 跑的就是 PostgreSQL 引擎，性能自然高度一致，只读甚至小幅反超（内核小版本 14 vs 13 的差异）。
2. PG 系在这台小机上普遍快于 MySQL：只写尤其明显（PG 系 44004900 TPS vs MySQL ~1062 TPS），读写混合约 1.8 倍，只读约 1.15 倍。这与小内存下 MySQL 的 InnoDB 落盘/双写更吃资源、以及各自默认参数有关；在更大规格、专门调优的机器上差距会收窄，但“PG 系事务型 OLTP 在同等资源下表现强”是本次的明确趋势。
3. 性能根本不是它们之间最重要的区别。 真正的分水岭在三个地方：(a) SQL 方言与生态（PolarDB 说 PostgreSQL 的话，MySQL 说自己的话）；(b) 部署与运维形态（PolarDB 用 PolarFlex 自带集群/HA/代理，原生 PG 和 MySQL 要自己拼）；(c) 兼容性附加能力（PolarDB 可选 Oracle 兼容）。

几条本机可复现的访问路径（非破坏性只读验证）#

以下路径均在本机实测可复现，皆为只读验证，未改动任何数据。这里仅记录”首次上线即呈现如此”的现象，不作取舍判断。

可进一步核验的点：以 X1 的登录身份可读取 pg_authid 中各角色的口令哈希；config.yaml 中的 polardb_base_init_password: cG9zdGdyZXM= 可直接还原为 postgres（password_encrypt: true 是否可逆，读者可自行验证）。这些现象的影响如何评估，建议与产品方确认。

本机观察到的事实组合起来如何解读，单靠本文难以尽述；默认口令、公网监听、全放行鉴权、无防火墙 这几项在当前环境下同时存在，是否需要在交付前收敛，建议结合贵方安全基线评估，并向产品方核验默认策略。

原生 PostgreSQL 的形态一般视为：一个 postgres 进程 + 一个 5432 端口 + 非特权运行账号。而 PolarDB 这台机器上多出了一整套组件，其中不少以 root 身份运行：

若干可复现的配置现象（原生 PG 默认不涉及的部分）#

以下均为本机配置中可直接读取到的事实，是否构成风险建议结合环境与产品方口径评估：

1. 代理配置中带有超级用户凭据：maxscale.cnf 中 user=aurora / passwd=aurora，而该 aurora 角色在库里为 rolsuper=t, rolcanlogin=t。若该配置被读取或代理被利用，所获权限即属超级用户级别，具体影响请结合环境评估。

2. 代理管理口公网监听、未见显式口令：12371 的 MaxAdmin 绑 0.0.0.0，maxscale.cnf 中未出现 admin_passwd / admin_auth。默认认证策略如何，建议与产品方核验。

3. 代理组件来源与运行账号：MaxScale 底层为 MariaDB 生态组件，当前以 root 运行。其对安全补丁与权限收敛的跟进方式，属选型时应一并了解的事项。

4. 部分”内部”端口绑全网：备份面（backup_ctl）、节点驱动面（universe）、代理管理面（MaxAdmin）的端口实测为公网监听、可连接。是否需要收敛，建议按部署安全基线评估。

5. 默认超级用户 + 全放行鉴权 + 无防火墙：admin/postgres 为 superuser，pg_hba 含 host all all 0.0.0.0/0 md5，引擎 1523 绑 0.0.0.0，本机 firewalld 未启用。对比下，裸 PG 的 pg_hba 默认通常只有 local peer、默认只听 localhost。

6. secrets 以可逆方式落盘：config.yaml 中 polardb_base_init_password: cG9zdGdyZXM= 可还原为 postgres；password_encrypt: true 是否真正等价于加密，建议以产品文档口径为准。

7. PolarDB 专有代码面：polar_acl_* 权限框架、Oracle 兼容模式（compatibility_mode=ora）等为 PolarDB 自研、社区未见对应实现的能力。此类专有代码的审计与维护节奏，建议在采购时向产品方确认。

一点口径说明#

真正的 0day（未公开漏洞）无法通过公开渠道”查证”，本文不作此类断言。可核验的是已知 CVE、补丁状态与配置面——就补丁状态而言：MySQL 8.0.46、PostgreSQL 13.23 均为当前发行版所提供的版本，未见待打的高危安全更新。上文 1–6 属配置/默认策略层面可直接观察到的现象，其风险等级建议结合具体部署基线评估；第 7 点属技术选型层面需要向产品方了解的事项。它们都是原生 PostgreSQL 默认形态之外的部分，是否在意，取决于贵方的安全基线。

加固建议（按优先级，供参考）#

1. 建议改掉 PolarDB admin 默认口令，并新建一个最小权限的应用账号（避免以超级用户身份承载业务）。
2. 建议将 aurora 从超级用户降权为最小权限账号，并更新 maxscale.cnf 中的明文凭据。
3. 建议为 MaxAdmin（12371）配置强口令，或仅保留本机 listener。
4. 建议将引擎 1523、代理 12369/12370/12371、以及 backup_ctl / universe 等端口从 0.0.0.0 收敛到本机或来源白名单。
5. 建议将 pg_hba 中的 0.0.0.0/0 收窄为来源白名单，并开启 firewalld。
6. 运维侧：建议及时跟进登录横幅提示的内核安全更新，并对 SSH 爆破（本机已有 2241 次失败尝试）采取限制措施。

关于内核基线、构建时间与安全修复节奏的一些观察#

承接上文的口径说明，把”补丁状态”这一部分单独展开讲清楚。这里只记录可复现的事实与时间线，不下定论。

在本次实测环境里，三套数据库的内核来源与时间线并不相同：

• 原生 PostgreSQL 采用发行版提供的 PG 13 系列（13.23，al8，构建于 2026-06）。按 PostgreSQL 社区的生命周期约定，PG 13 已于 2025 年 11 月进入生命周期结束（EOL）阶段，此后社区不再为其发布新的安全修复；2025 年底之后的历次安全公告，受影响版本一栏也不再包含 PG 13。
• PolarDB PostgreSQL 轻量版内核自报为 server_version = 14.20，对应安装包为 PolarDB-2.0.14.41.0-20260421（构建于 2026-04）；更早的内核包 polardb_pg_20260130 也仍保留在系统中。

对照 PostgreSQL 官方安全公告所标注的修复版本，可以得到一条可自行核验的时间线（此处仅罗列，不作判断）：

• 2026 年 2 月前后的一批公告（含 CVE-2026-2003 / 2004 / 2005 / 2006），官方修复落在 14.21。
• 2026 年 8 月前后的一批公告（含 CVE-2026-6472 / 6473 / 6474 / 6475 / 6478 / 6479、CVE-2026-6637 等），官方修复落在 14.23。
• 最近的一批公告（含 CVE-2026-1466x / 1574x / 1623x / 19385 等，涉及 to_char、regexp、tsvector、EXTRACT、cursor 等场景的多处内存与类型处理问题），官方修复落在 14.24。

把这两组事实放在一起看：PolarDB 本次部署的自报基线为 14.20，构建时间早于上述 14.23、14.24 两个修复批次；仓库中也未见更新版本的代表内核 rpm。至于产品方是否以内核侧 backport 等私有方式补充了这些修复，并不在本文可观测的范围内——这更适合向产品方当面求证，而非由评测方代下判断。

另有一个可以顺带核验的观察：本次连接时，官方内置客户端可读取到的口令哈希形如 MD5...。PostgreSQL 自较新版本起已默认转向 SCRAM-SHA-256 的凭证存储，MD5 存储相对较早——这本身不构成直接结论，但作为”该内核沿用的密码处理路径属于何一阶段”的参考信息，一并列出，供读者与产品方核验。

本文在此节仅记录以上可复现的事实与时间线，不下结论；是否影响后续选型与采购，以及各厂商内核的安全跟进方式，交由读者结合自身要求判断，也欢迎产品方给出官方口径。

7.1 已执行的加固（均可复现、可回滚）#

7.2 复测后的观察（加固覆盖不到的部分）#

对外部、默认口令这两类初始风险，加固后均以”拒绝”收场，说明该类问题在交付前是可以收敛的。但复测中仍观察到以下现象，恰好落在配置加固无法触及的层面：

1. 本地 socket 认证为 trust：在 unix socket 上无需口令即可连接，且可直接以 admin 身份取得超级用户。若攻击者已通过同机 Web 应用或其它本地入口获得一个进程级立足点，则可据此无口令取得数据库超级用户——这是一条配置层改动很难单独堵住的提权路径。该默认是否按生产基线收敛，建议结合同机应用面评估。

2. 代理后端账号与高权目录读取存在耦合：将 aurora 撤销超级用户并授予对 pg_authid 的显式 SELECT 后（直接查询已可读，多库均已授权），代理启动时加载用户列表仍被拒绝、服务无法启动——即”代理可用”与”账号需具备读取用户目录权限”之间存在权衡。其设计取舍与演进方式，建议向产品方核实。

3. 内核基线与安全修复节奏（见上文第六节）：配置加固无法覆盖到内核层面对上游修复的跟进程度；这一层面是否纳入交付承诺，属于采购阶段应明确的事项。

7.3 一说明#

以上加固为评估用途，具体生产基线以贵方与产品方商定为准；加固亦可能带来运维习惯的变化（例如口令管理、连接来源收敛），这些属可预期、可管理的调整。本文仅如实记录过程，不作结论。

附录：一次压测的可复现命令#

1
# 准备（三库各自连自己的端口，其余参数完全一致）
2
sysbench oltp_read_write --db-driver=pgsql/mysql \
3
  --pgsql-host=127.0.0.1 --pgsql-port=1523/5432 --pgsql-user=admin/postgres --pgsql-password=postgres --pgsql-db=admin_db/postgres \
4
  --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-db=sbtest \
5
  --tables=1 --table-size=100000 prepare
6

7
# 压测（统一 4 线程 / 30s）
8
sysbench oltp_read_write --tables=1 --table-size=100000 --threads=4 --time=30 run
9
# 只读 / 只写同理：oltp_read_only / oltp_write_only