universal-db-mcp新增多Schema支持，解决PostgreSQL多库访问难题

背景

在 AI 辅助数据分析与数据库管理的场景中，Model Context Protocol (MCP) 插件 universal-db-mcp 因其“万能连接器”的特性，旨在通过自然语言查询和分析各类数据库数据。然而，随着社区用户深入使用，特别是针对复杂企业级数据库架构的测试，暴露出了该工具在多 Schema（模式）支持上的显著缺陷。

一位名为 @Cyrus42 的社区用户在使用 PostgreSQL 数据库时，发现当数据库包含多个 Schema（如 production、analytics、staging 等）时，universal-db-mcp 的工具（如 get_table_info）仅能检索到默认的 public Schema 中的表，导致其他自定义 Schema 下的表信息无法访问，甚至引发“表不存在”的错误。这一反馈促使项目方对底层架构进行了深度复盘与重构，最终发布了支持多 Schema 的更新版本。

核心内容

本次更新的核心在于解决 universal-db-mcp 在处理多 Schema 数据库时的兼容性断裂问题。项目方通过四个层次的分析，定位了从 SQL 查询到 API 接口的完整阻断链，并实施了相应的修复方案。

问题根因分析

问题并非单一代码错误，而是分布在四个技术层次：

1. Adapter 层（核心根因）： 各数据库适配器的 _getSchemaImpl() 方法中，元数据查询 SQL 硬编码了默认 Schema 的过滤条件。例如，PostgreSQL 系数据库硬编码了 nspname = 'public' 或 table_schema = 'public'，导致系统只能读取 public Schema 的元数据。每个受影响的适配器中，约有 5 条 SQL 查询（涉及列、主键、索引、行数/注释、外键）存在此问题。

2. 类型定义层： 在 src/types/adapter.ts 中，TableInfo 接口仅包含 name: string，缺乏 schema 字段。这意味着即使适配器能返回多 Schema 的表，系统也无法区分 public.users 和 analytics.users，导致数据标识冲突。

3. DatabaseService 层： src/core/database-service.ts 中的 quoteIdentifier() 函数将表名视为单一标识符处理（如 "analytics.users"），而非标准的 Schema 限定名格式（如 "analytics"."users"）。这导致 get_enum_values 和 get_sample_data 等工具在构建 SQL 时无法正确引用带 Schema 前缀的表名。

4. 工具/API 层： MCP 工具（如 get_table_info、get_enum_values）的 inputSchema 以及 HTTP API 路由中，仅包含 tableName 参数，缺失 schema 参数，使得用户无法在调用时指定目标 Schema。

受影响范围

• 受影响的数据库适配器（8 个）：

  • PostgreSQL 系：PostgreSQL、GaussDB/OpenGauss、KingbaseES、Vastbase、HighGo。这些数据库均因硬编码 nspname = 'public' 而受影响，严重程度为“高”。
  • SQL Server：因使用 SCHEMA_NAME() 或 SCHEMA_ID() 过滤，受影响，严重程度为“高”。
  • Oracle & 达梦 (DM)：因使用 OWNER = USER 或 USER_* 视图过滤，受影响，严重程度为“中”。

• 不受影响的数据库适配器（9 个）：

  • MySQL 系：MySQL、TiDB、OceanBase、PolarDB、GoldenDB。这些数据库通常以 DATABASE() 作为隔离单位，无多 Schema 概念。
  • 其他：ClickHouse（按 database 隔离）、SQLite（单文件）、MongoDB 和 Redis（NoSQL，不适用 Schema 概念）。

修复方案

1. SQL 查询重构：适配器不再硬编码默认 Schema，改为排除系统 Schema 并自动发现所有用户 Schema。
2. 命名规范统一：非默认 Schema 的表名采用 schema.table_name 格式（如 analytics.events）返回；默认 Schema 表名保持不变，以确保向后兼容。
3. 接口增强：get_table_info 等工具现在支持通过 schema.table_name 格式精确指定表，无需额外配置。

关键要点

• 多 Schema 支持已实现：更新后，universal-db-mcp 能够自动发现并访问用户有权限的所有 Schema 中的表，解决了以往只能访问默认 Schema 的局限。
• 向后兼容性保持：对于仅使用默认 Schema（如 PostgreSQL 的 public、SQL Server 的 dbo）的用户，使用体验完全不变，无需修改现有配置或代码。
• 命名约定变更：非默认 Schema 的表在工具返回中将以 schema.table_name 的形式呈现（例如 analytics.events），用户需适应这一命名格式进行查询。
• 全面覆盖主流关系型数据库：修复覆盖了 PostgreSQL、SQL Server、Oracle 等主流企业级数据库，这些数据库在多租户、数据分层或模块化设计中广泛使用多 Schema 架构。
• 无需配置变更：升级后自动生效，用户无需调整启动参数或配置文件即可享受新功能。
• 典型应用场景解锁：
  • 多租户架构：每个租户独立 Schema 的查询。
  • 数据分层：区分开发、测试、生产环境的 Schema。
  • 数据仓库：访问原始、清洗、聚合等不同阶段的 Schema。
  • 模块化设计：按业务模块（如用户、订单）划分的 Schema。

意义与影响

此次更新标志着 universal-db-mcp 从“基础连接”向“企业级兼容”迈出了关键一步。

1. 提升企业级可用性：大多数中大型企业数据库均采用多 Schema 架构以实现数据隔离、权限管理和模块化设计。此前，universal-db-mcp 在这些场景下几乎不可用。修复后，该工具真正具备了处理复杂企业数据库的能力，极大地扩展了其适用边界。
2. 增强数据洞察的完整性：用户不再需要被迫将所有表放入默认 Schema 以规避工具限制，从而保持了数据库设计的合理性和可维护性。AI 助手现在能够全面访问所有业务数据，提供更准确、完整的数据分析和查询服务。
3. 社区驱动优化的典范：此次更新源于社区用户 @Cyrus42 的详细 Issue 报告，包括复现步骤、根因分析和业务影响评估。这体现了开源社区协作的价值，也证明了 universal-db-mcp 项目方对社区反馈的快速响应和严谨的技术态度。
4. 降低 AI 数据集成门槛：通过自动发现 Schema 和标准化的 schema.table_name 命名，降低了用户在使用 AI 工具连接复杂数据库时的配置和学习成本，使得自然语言数据分析更加直观和高效。