多 MySQL MCP Server 如何实现多数据库连接、只读模式和 SQL 注入防护？

Multi-MySQL MCP Server 通过一个 MCP 进程管理多组 MySQL 与 MariaDB 连接，并用标签选择目标数据库。它提供查询、库表探索、表结构描述、健康检查和执行计划等七个工具，同时加入只读事务、SQL 状态机检查、预处理参数、连接池与配置热重载。这样的架构适合让编码助手在多个项目数据库之间切换，但连接数量越多，越需要把路由、凭据和权限边界设计清楚。

项目文档将其描述为默认安全，不过“默认安全”应理解为多层防护的起点。应用层解析可能有方言边界，只读会话不决定可以读取哪些敏感数据，参数化也不能自动保护一整段由模型生成的 SQL。生产环境仍要使用每库独立的最小权限账号、网络隔离和审计。

一个服务如何管理多个数据库

配置文件中的 connections 数组保存多条连接，每条都拥有唯一 label，以及主机、端口、账号、密码、默认 database、TLS、readOnly、enabled 和 poolSize 等字段。

工具调用通过 label 选择连接池，而不是让模型提交任意主机或连接串。服务只应访问启动时配置并启用的连接，避免 Agent 把它变成通用数据库代理。

label 应使用稳定、无歧义的名称，例如 orders-staging，而不是 db1。工具响应同时显示环境与数据库名，可降低把测试操作发到生产的概率。

为什么 label 是安全边界

同一个进程能看到多套连接时，模型可能因上下文混淆选择错误 label。若生产与开发都暴露，正常只读查询也可能从生产读取敏感数据。

项目提供 --label 参数，只向当前 MCP 实例暴露一条相关连接。为每个项目配置独立 MCP 启动项，并固定 label，比让模型每次自由选择所有数据库更可靠。

服务端仍要验证 label 精确匹配，不能使用前缀、模糊搜索或客户端传入路径。错误 label 应明确拒绝，不自动回退到第一条或默认生产连接。

连接池如何工作

每条连接可以设置 poolSize，默认值为五，允许范围一到一百。连接池复用 TCP、TLS 和认证会话，减少每次工具调用重新连接的开销。

多数据库场景的总连接数是各连接池上限之和。十个标签各配置二十条连接，理论上就可能占用两百个数据库会话。不能只看单池数值。

上线前计算所有 MCP 实例、用户与副本的最大连接数，并为数据库预留应用和运维容量。查询超时不等于连接上限，短查询高并发同样会压垮实例。

热重载的收益与风险

热重载允许修改配置后更新连接，而不重启 MCP 进程。它适合轮换凭据、临时禁用数据库或调整连接池。

配置变化必须原子应用。新文件先完成结构校验和必要连接测试，再替换当前配置；不能在半写入状态关闭旧池或暴露不完整连接。

删除或修改连接时，要定义正在执行的查询如何结束、旧连接池何时销毁，以及失败时是否回滚到上一版本。热重载日志不能包含密码和完整 URL。

环境变量展开

配置字符串支持变量和带默认值的变量语法，可把账号密码留在环境或秘密管理中，而不是明文提交 JSON。

敏感变量不应设置弱默认值。生产密码缺失时必须启动失败，不能悄悄使用开发账号或空密码。

变量展开后的完整配置属于秘密。调试输出、校验错误和健康检查响应只能显示脱敏主机与 label，不回显凭据。

状态机解析器解决什么

项目使用状态机识别多语句和危险结构，专门考虑 MySQL 的反引号标识符、井号注释与反斜杠转义。这比按分号简单 split 更可靠。

分号可能位于字符串、注释或反引号标识符内，不应被视为语句结束。反过来，注释和转义也可能用来隐藏第二条语句，状态机必须保持当前词法上下文。

这种检查主要阻止 statement stacking，并为明显违规提供快速错误。它不是完整 MySQL 语法解析器，不能单独证明任意输入无害。

DDL 防护

服务会阻止 CREATE、DROP、ALTER 和 TRUNCATE 等 DDL。只检查第一个词不够，因为注释、WITH、EXPLAIN 或复合结构可能改变表面形式。

应测试不同大小写、前导注释、版本条件注释、换行和多语句组合。MySQL 的版本条件注释可能包含服务器实际执行的代码，是普通注释过滤器容易忽略的边界。

数据库账号本身也不应拥有 CREATE、ALTER、DROP、INDEX、TRIGGER、EVENT 或 ROUTINE 管理权限，形成引擎层兜底。

只读模式如何执行

readOnly 默认开启，项目使用 SET SESSION TRANSACTION READ ONLY 包裹查询。数据库服务器会在事务语义层拒绝常规写操作。

会话级状态与连接池结合时必须特别谨慎。连接归还池之前应确保事务结束，并恢复所有会话变量；否则一次调用的状态可能污染下一位用户。

只读事务也不能限制 SELECT 能读取哪些库表，更不能阻止大查询。每条连接仍需配置专用只读账号，只授予批准对象的 SELECT。

为什么不能只依赖 readOnly 配置

配置文件可被误改，热重载也可能载入 readOnly false。若连接账号拥有写权限，一次配置事故就会移除关键边界。

真正只读的生产连接应在 MySQL GRANT 层没有 INSERT、UPDATE、DELETE 和 DDL 权限。应用标志与账号权限同时生效，任何一层失效都不直接造成写入。

对确实需要写入的开发连接，使用不同账号、不同 MCP 实例和明显 label，不要在同一项目中混用。

预处理语句保护什么

项目通过 connection.execute 和问号占位符绑定用户参数。参数作为数据传输，不会被数据库解释为 SQL 结构，这是防止传统参数注入的标准方法。

但 mysql_query 的 SQL 主体本身由 Agent 生成。预处理不会判断 SELECT 是否越权，也不会把 DROP 自动变成普通字符串。

表名、列名、排序方向等标识符通常不能用占位符绑定。结构探索工具应使用固定 SQL，并对白名单标识符做严格验证与引用。

SQL 注入防护的准确表述

应把整体能力拆成三部分：状态机阻止多语句与明显绕过，参数化保护独立参数，只读事务拒绝写入。三者覆盖不同威胁。

不能笼统承诺“防止所有 SQL 注入”。如果账号可读敏感表，注入出的 SELECT 仍可能泄露数据；如果允许高风险函数，单条语句也可能产生副作用。

安全验收应根据实际工具参数和数据库权限建立威胁模型，而不是只检查 README 中是否出现 injection protection。

七个工具如何分工

mysql_list_databases 列配置连接状态，mysql_list_schemas 探索服务器上的库，mysql_list_tables 返回表、估算行数、引擎和大小，mysql_describe_table 返回列与约束。

mysql_query 执行只读查询，mysql_explain 查看执行计划，mysql_health_check 测试版本、连通性和延迟。

元数据同样敏感。生产账号若能列出所有 schema，Agent 可能了解其他租户和内部系统结构。工具输出范围应与 label 和账号授权一致。

EXPLAIN ANALYZE 的特殊风险

普通 EXPLAIN 主要生成计划，而 EXPLAIN ANALYZE 会实际执行目标语句以获得运行统计。项目因此把它放入事务并在结束时 ROLLBACK。

回滚可以撤销数据库事务内修改，却无法撤销外部副作用，也不能消除查询带来的锁、CPU 和 IO 消耗。只读账号与只读事务仍应同时存在。

生产环境可优先使用普通 EXPLAIN。只有明确需要真实执行统计时才允许 ANALYZE，并使用更短超时和低权限副本。

MySQL 与 MariaDB 差异

项目声明兼容多个 MySQL 与 MariaDB 版本，但两者在语法、系统表、EXPLAIN 输出、事务特性和版本注释行为上存在差异。

不能只在一个 MySQL 版本测试就推断所有声明环境都安全。每个生产版本都应跑多语句、注释、转义、只读事务和执行计划回归。

云数据库还可能限制会话变量或提供代理层。RDS、Cloud SQL、PlanetScale 等环境应按实际行为验收，不仅依赖兼容列表。

存储引擎影响事务保证

mysql_list_tables 会显示 InnoDB、MyISAM 等引擎。InnoDB 支持事务，MyISAM 不提供相同的事务回滚语义。

如果环境仍有非事务表，不能假设 ROLLBACK 能撤销所有影响。最稳妥的方法是账号没有写权限，并把 Agent 可访问对象限制到批准的 InnoDB 表或只读视图。

执行计划和元数据工具也应避免对大表做精确 COUNT，优先使用统计估算，以免探索动作变成昂贵扫描。

配置文件权限检查

项目会在 Unix 上警告配置文件对所有用户可读。这能发现常见的明文密码泄露，但警告不等于强制阻断。

配置文件应仅运行账号可读，目录不可被 Agent 修改。更好的是配置只保存变量引用，真实秘密由进程环境或秘密代理提供。

Windows、容器卷和网络文件系统有不同 ACL 模型，需要各自验证，不能只依赖 Unix mode 检查。

Zod 配置校验

严格 schema 校验可以拒绝未知字段、错误类型、重复或缺失关键值，避免把 readOnly 字符串误当布尔值等问题。

结构合法不代表安全。例如 poolSize 一百可能合法，却不适合小型数据库；生产连接 readOnly false 也可能通过类型校验。

在 Zod 之外增加组织策略检查，例如生产 label 必须只读、必须启用 TLS、禁止明文密码和限制连接池总量。

TLS 与云数据库

ssl 字段支持布尔或对象配置，可用于云 MySQL。仅打开 TLS 还需验证服务器证书与主机名，避免接受任意自签名证书。

数据库密码和查询结果都可能包含敏感信息，跨网络连接必须加密。私网也不应默认可信。

证书轮换要与热重载协调，先建立新连接再关闭旧池，并确保失败不会回退到未加密连接。

健康检查不要泄密

mysql_health_check 返回连通性、版本和延迟，适合运维诊断。它不应回显密码、完整 URL、服务器内部错误栈或其他连接配置。

健康检查成功只证明当前能连接，不证明账号最小权限、只读事务和策略有效。部署测试还要真实尝试受允许与受拒绝操作。

频繁健康检查也占用连接，应使用合理间隔，并区分数据库不可达、认证失败和池耗尽。

多连接最小权限设计

每个 label 使用不同账号，不让一套凭据横跨开发、测试和生产。即使多个数据库位于同一实例，也按业务边界分别授权。

生产账号只拥有目标 schema 与表的 SELECT，撤销 FILE、PROCESS、SHOW DATABASES 和管理权限。敏感列通过视图或列权限排除。

在 MySQL 中，读取 information_schema 和性能信息可能暴露实例活动；是否需要这些数据应按工具功能单独授权。

防止跨项目误用

为每个代码仓库创建只包含相关 --label 的 MCP 配置。不要让通用用户级配置暴露所有生产数据库。

项目配置可以共享启动参数，但不能提交连接密码。对生产实例要求额外身份验证或人工审批，比依赖模型选择 label 更稳妥。

工具响应中持续带回选中的 label，让用户在每次重要查询前能确认目标。

必须覆盖的注入测试

测试普通 SELECT、字符串中的分号、反引号中的特殊字符、井号与双横线注释、块注释、反斜杠转义和不同字符集。

测试分号堆叠、版本条件注释、CTE 写入、DDL、事务控制、存储过程、用户变量、INTO OUTFILE 和高权限函数。

为每个 MySQL 与 MariaDB 生产版本执行同一套回归，并检查语句不仅被应用层拒绝，数据库账号本身也不能完成危险操作。

资源与稳定性测试

并发占满所有连接池，确认额外请求受控排队或快速失败，不会无限积压。热重载期间重复查询，确认不存在旧连接泄漏。

运行慢 JOIN、锁等待和 EXPLAIN ANALYZE，验证超时、取消、回滚与连接归还。检查非事务表和外部函数边界。

把大结果查询与客户端断连组合测试，确认服务不会在内存中缓存无限数据，也不会留下长时间运行的数据库会话。

上线检查清单

确认每个连接 label 唯一、明确且按项目隔离；生产 MCP 使用 --label，只暴露必需数据库。

确认 readOnly 默认值没有被覆盖，每库账号原生只读，TLS 正确验证证书，配置和秘密权限严格。

确认状态机覆盖目标方言的注释与转义，多语句和 DDL 被拒绝，所有参数使用预处理，结构标识符来自白名单。

确认连接池总量、查询超时、结果大小和并发适合实例容量；EXPLAIN ANALYZE 仅在批准环境使用。

确认热重载原子完成、旧池正确关闭、日志不含秘密，并为配置变化、拒绝事件和异常查询建立审计告警。

多数据库故障需要隔离

一个标签对应的数据库不可达时，不应拖垮其他连接池。健康状态、重试计数和断路器要按 label 分开，不能因为生产库超时让开发库查询也排队。

连接重试使用指数退避和随机抖动，避免数据库恢复瞬间所有池同时重连。认证失败通常不是瞬时故障，不应无限重试并持续触发账号锁定。

热重载加入坏连接时，应保留其他已验证连接；删除连接后则立即阻止新请求，并让在途查询在规定时间内结束。服务整体的 ready 状态可以表达部分可用，工具响应仍要精确指出失败 label。

审计必须关联具体连接

每次工具调用至少记录请求时间、客户端会话、label、脱敏后的数据库目标、工具名、查询摘要、只读状态、耗时、返回行数和结果状态。否则多个库共用一个 MCP 进程后，很难还原查询实际落到了哪里。

完整 SQL 可能包含个人信息和商业数据，日志要做参数脱敏并限制保留期。连接 URL、密码和展开后的环境变量永远不进入日志。

审计存储应与 Agent 查询权限隔离，并为生产 label 的异常频率、拒绝 DDL、连续全表查询和大量 schema 探索建立告警。安全事件发生时，可以只禁用受影响 label，而不必关闭全部数据库访问。

Multi-MySQL MCP Server 的多数据库能力来自标签化连接和独立连接池，安全性则来自状态机检查、DDL 阻断、预处理参数和只读事务的组合。可靠部署的关键不是相信单个“防注入”开关，而是让 label 隔离、数据库权限、协议解析、事务、资源限制和秘密管理共同生效。这样一个 MCP Server 才能便利地访问多库，而不会把所有数据库合并成一个过大的信任域。