postgres_fdw查询慢的主因是条件或函数未下推，导致全表拉取；EXPLAIN可查Remote SQL确认下推情况，建议用远程视图、避免本地变量、升级或手动建表。
postgres_fdw 查询慢，是不是因为没下推？
绝大多数 postgres_fdw 性能问题，根源是远程查询没做条件或函数下推，导致全表拉到本地再过滤。PostgreSQL 默认只下推简单 WHERE 中的常量比较（如 id = 123），但遇到 LIKE、IN (subquery)、自定义函数、ORDER BY 带表达式等情况，就会放弃下推，走本地执行。
实操建议：
- 用
EXPLAIN (VERBOSE, ANALYZE)查看执行计划，重点找Remote SQL:行——如果它里面没有WHERE或只有极简条件，说明下推失败 - 把复杂逻辑拆到远程视图里，再用
postgres_fdw映射该视图，比直接映射基表更可控 - 避免在
WHERE中使用本地临时表、current_user等无法下推的值；必要时改用IMPORT FOREIGN SCHEMA+ 手动建FOREIGN TABLE并加OPTIONS (table_name '...') -
postgres_fdw不支持跨库事务一致性，远程写操作（INSERT/UPDATE/DELETE）需额外处理错误回滚边界
mysql_fdw 连不上 MySQL 8.0，报错 ERROR: failed to connect to server
常见于 MySQL 8.0 默认启用了 caching_sha2_password 插件，而老版本 mysql_fdw（v2.5.1 之前）只认 mysql_native_password。不是密码错，是认证协议不兼容。
实操建议：
- 远程 MySQL 创建用户时显式指定插件：
CREATE USER 'fdw_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - 或者升级
mysql_fdw到 v2.6+，并确认编译时链接的是 MySQL 8.0 client library（非 mariadb-client） -
mysql_fdw不支持 prepared statement 下推，所有参数都会拼成文本 SQL 发送，有注入风险——绝不能把用户输入直传进WHERE条件 - 连接池靠 PostgreSQL 后端进程维持，每个 backend 单独连，高并发下容易触发 MySQL 的
max_connections限制
dblink 和 postgres_fdw 能否混用？什么场景该选 dblink？
能混用，但别为了“统一”硬凑。dblink 是过程式调用，postgres_fdw 是声明式映射，二者定位完全不同。
实操建议：
- 只读、固定结构、高频访问的跨库表 → 用
postgres_fdw，可建索引、参与 JOIN、被物化视图引用 - 一次性取数、结果结构不固定（比如动态列）、需要执行 DDL 或存储过程 → 用
dblink，例如：SELECT * FROM dblink('host=x port=5432', 'SELECT now(), pg_backend_pid()') AS t(a timestamptz, b int); -
dblink不校验远程表结构，SQL 写错才报错；postgres_fdw建表时就检查字段类型，错配会直接失败 -
dblink连接串明文写在 SQL 里，密钥管理麻烦；postgres_fdw可配合user_mappings+.pgpass或 GSSAPI 集中管控凭据
跨库查询权限和网络暴露面怎么收窄？
fdw 类扩展本质是让 PostgreSQL 进程以指定用户身份直连远端数据库，权限控制必须从两端卡死，不能只靠防火墙。
实操建议：
- 远程数据库只给 fdw 用户最小权限：MySQL 上仅
SELECT（或必要时INSERT/UPDATE）对应库表；PostgreSQL 上用GRANT SELECT ON TABLE ... TO fdw_user;，禁用SUPERUSER和CREATEDB - fdw 服务端不要监听公网（
listen_addresses = 'localhost'或内网地址），用 SSH 隧道或 VPC 对等连接替代开放端口 - 避免用
publicschema 映射远程库；导入时用IMPORT FOREIGN SCHEMA xxx FROM SERVER yyy INTO fdw_schema;，隔离命名空间 -
mysql_fdw和postgres_fdw都不加密传输内容（除非底层 TCP 层启用 TLS），敏感字段务必在应用层脱敏，别依赖 fdw 隐藏
最易被忽略的一点：fdw 的远程连接复用行为不透明，连接空闲超时、后端崩溃、远端重启都可能导致静默失败，生产环境必须配合 connect_timeout 和 keepalives 参数，并在业务层做重试兜底。
