CherryStudio配置MySQL MCP服务器：从环境搭建到安全加固全指南

我一直有个习惯：凡是带API的AI客户端，本地装好之后，一定要想办法让它能碰到真实数据，而不是永远在云端模型的知识边界里打转。CherryStudio最近几个版本把MCP支持做得很顺手，我就在里面把mysql_mcp_server完整配置了一遍。这篇文章就是这次配置的全过程记录，从Node.js环境检查、npm包选择，到CherryStudio客户端里添加MCP服务器，再到各种报错排查，最后顺手把数据库权限也收紧了一圈。适合两种人看：一种是刚接触MCP、不知道MySQL怎么接到AI助手里的新手；另一种是配置了但连不上、正在被一串英文报错折磨的老手。

先把结论放在前面：整个链路不复杂，就是“CherryStudio在本地拉起一个Node.js进程，这个进程通过MCP协议和AI对话，再把AI的意图翻译成SQL发给MySQL”。但正因为有三方参与——CherryStudio、Node.js进程、MySQL服务——任何一个环节断掉，表现出来都是一句莫名其妙的错误。所以这篇文章我会按“环境准备→包获取→客户端配置→验证→排查→权限安全”的顺序讲，每一步都带可复现的命令和参数。

1. 先搞懂MCP服务器在CherryStudio里的位置：它不是插件，而是一个本地翻译官

1.1 MCP到底解决了我什么问题

Model Context Protocol（MCP）说白了就是一个标准化接口协议，让AI客户端不用为每个数据源单独写对接逻辑。你可以把它理解成USB-C统一了充电接口：以前每个设备一个充电线，现在一根线走天下。MCP做的事情类似，它把“数据库”“文件系统”“HTTP接口”这些外部能力统一包装成一种协议形态，AI客户端只需要实现一次MCP客户端逻辑，就能接入所有实现MCP服务端的工具。

具体到CherryStudio这里，客户端内置了MCP Client能力。我只需要提供一个能启动MCP Server的命令，CherryStudio就会替我管理这个子进程的生命周期，包括启动、发送请求、接收响应、退出。这个设计有个很关键的好处：数据库连接信息、查询逻辑这些东西，全部留在本地运行，不需要提交到云端模型服务商那里，模型只是收到“这个工具返回了什么结果”。

1.2 mysql_mcp_server在链路里负责什么

mysql_mcp_server就是一个典型的MCP服务器实现，它内部连接MySQL，向外暴露一组和数据库操作相关的工具，比如执行SQL查询、列出数据库列表、获取表结构等。当你在CherryStudio对话里问“看看orders表里有多少行”，模型会判断需要调用MCP工具，然后CherryStudio通过本地进程通信，把调用请求发给mysql_mcp_server。

mysql_mcp_server收到请求后，会把“调用工具”的动作转换成真正的SQL语句，连上MySQL执行，再把查询结果转成结构化的数据返回给CherryStudio。最终你在对话界面看到的，就是一段模型整理过的文字，加上一张渲染出来的结果表格。

这条链路上有一个很容易被忽略的点：模型本身并不直接触达MySQL。模型只知道“我有一个工具可以用”，工具的具体实现、数据库地址、密码、SQL语法，全在mysql_mcp_server这个进程里。所以MCP服务器其实是一个翻译官和守门人的双重角色，这也是为什么后面要单独花一章讲数据库权限。

1.3 为什么配置入口在CherryStudio而不是模型服务商后台

这个问题我一开始也绕了一下。模型API跑在云端，为什么MCP配置却落在本地客户端？原因很简单：MCP是客户端侧的协议，它决定了“我的本地环境里有哪些工具可以被模型调用”。模型服务商只知道“你上传的API请求里带了一堆工具定义”，它不关心这些工具跑在哪里，也管不到你的内网数据库。

就好比你给员工配了一部手机，手机上装什么App是你自己的事，总部不会替你去安装通讯录。CherryStudio负责把本地MCP服务器“登记”成工具清单，在每次对话时把工具的JSON Schema发给模型，模型看到有“mysql_query”这个工具，就会在需要时请求调用它。顺着这个理解，配置过程中遇到的大多数问题都能归位——不是模型不支持，而是本地进程没起；不是协议没通，而是Node.js环境有问题。

2. 配置前就得解决的Node.js环境：我见过八成配置失败都栽在这一步

2.1 为什么非得有Node.js

你看网上各种mysql_mcp_server教程，十有八九都会忽略“先确认Node.js版本”这一步。但实际上，这不是可选步骤。绝大多数MCP MySQL服务器都是以npm包形式分发的，npm是Node.js自带的包管理器，没有Node.js环境，你连包都拉不下来。

还有一个更重要的原因：在CherryStudio里配置stdio类型的MCP服务器时，你填的“命令”和“参数”最终会由CherryStudio调用系统来执行。如果这个命令是npx，那么本机必须要有Node.js，而且npx必须能在GUI应用的可执行路径里被找到。这一条后面4.3节会重点说，先记住：没有Node.js，后面所有步骤都免谈。

2.2 检查环境：node -v 和 npm -v

打开终端（Windows上按Win+R输入cmd回车，macOS和Linux打开Terminal），逐条执行：

bash复制node -v
npm -v

如果两条命令都有输出，比如v18.20.4和10.7.0，说明环境已经就绪。如果提示'node' 不是内部或外部命令，或者command not found，说明Node.js没有安装或没有加入PATH。

版本上，建议Node.js 18及以上。MCP相关的npm包对Node版本有要求，老版本很容易在启动时冒出error: unknown option --host或者依赖编译失败。如果你检查出来是Node 16甚至更旧，别犹豫，直接升级。我自己实测Node 18和Node 20都能稳定跑mysql_mcp_server，Node 20稍微快一点，但差别不大。

2.3 Node.js安装的三种方式以及我推荐哪种

以Windows为例，最简单的方式是去Node.js官网下载LTS版本的安装包，一路“下一步”装完，Node.js和npm都会自动配置到系统PATH。装完之后一定重启一下终端（好多个配置失败就是没重启会话导致环境变量没生效）。

如果你需要经常切换Node版本，或者在多个项目之间横跳，我更推荐用nvm来管理。Windows上装nvm-windows，Linux和macOS使用nvm脚本，然后用nvm install 20、nvm use 20切换版本，以后做别的MCP服务器或者前端项目也方便。

macOS用户如果装了Homebrew，一行命令就行：

bash复制brew install node

无论哪种方式，装完都回2.2重新执行一遍检查命令，确认输出版本号再往下走。

2.4 npm镜像源：并不是必须，但会让你少等十分钟

很多人的第一个坑不在配置，而在拉包。npm官方源的下载速度在国内有时候很难看，一个几十MB的包能等半天。这个和功能无关，纯粹是网络问题，但确实会让人误以为卡住了。

先看一下当前registry配置：

bash复制npm config get registry

如果返回的是https://registry.npmjs.org/，而你又觉得下载慢，可以换成国内镜像源：

bash复制npm config set registry https://registry.npmmirror.com

换完之后再拉包，速度通常会有明显改善。需要说明的是，这只是把npm的下载源换了，对mysql_mcp_server本身的功能没有任何影响，属于“加速但不改变行为”的操作。

2.5 一个关键认知：终端能用不等于CherryStudio能用

这是我踩过最大的一个坑，必须单独拿出来说。很多时候你在终端里敲node -v、npm -v都正常，MCP服务器在终端里也能启动，但一进CherryStudio就报spawn npx ENOENT。

原因在于：终端（比如CMD、PowerShell）启动时会读取用户和系统的PATH环境变量，而图形界面应用（尤其是像CherryStudio这种Electron应用）在启动时读取的PATH不一定和终端一致，特别是那些通过桌面快捷方式启动、而不是从终端里启动的应用。Windows下用nvm安装的Node如果没走系统级PATH，这个问题就更明显。

解决办法有两条路：一是装完Node后彻底重启系统，让所有进程都能读到最新PATH；二是我后面4.3节会讲的，在CherryStudio里直接填Node和脚本的绝对路径，绕过PATH问题。现在先记住这个认知，后面配置报错时能省好几个小时。

3. 拿到并验证mysql_mcp_server：包名、运行方式和连接参数一起说清楚

3.1 先确认你要装的包是哪一个

“mysql_mcp_server”这个名字本身不是某个npm包的唯一标准包名，社区里存在多个实现。有的包叫@benborla/mcp-server-mysql，有的叫mysql_mcp_server，还有各种叫mcp-server-mysql-xxx的仓库。如果你在CherryStudio里看到的项目文档明确指定了某个包，直接用那个；如果没有指定，我建议搜索一下再决定。

bash复制npm search mcp mysql --json

输出里能看到包名、描述、下载量。挑下载量比较高、维护时间比较近的。我这篇文章以@benborla/mcp-server-mysql为例来说明，因为它的环境变量设计和命令行参数方式都对CherryStudio很友好。就算你最后选的是另一个包，配置思路也是一样的：确认启动命令、确认连接参数、在终端验证、再进CherryStudio。

3.2 全局安装还是npx直跑，我两个都给你

获取mysql_mcp_server有两种常见方式，各有适用场景。

第一种是用npx直接运行，不用先安装。命令里的-y表示自动确认下载：

bash复制npx -y @benborla/mcp-server-mysql --help

这种方式的优点是干净，不会污染全局node_modules；缺点是每次运行都可能在本地缓存查找不中时重新拉包，而且一旦CherryStudio的PATH读取不到npx，这条路就走不通。

第二种是全局安装，把MCP服务器变成一个全局命令：

bash复制npm install -g @benborla/mcp-server-mysql

装完之后，你可以在终端里直接执行mcp-server-mysql --help或者mcp-server-mysql --host=...来启动。对CherryStudio来说，我建议优先用全局安装，因为这样你能拿到一个确切的命令名，甚至能通过npm root -g找到完整的安装路径，后面配置时可以直接填绝对路径，彻底绕开PATH问题。

3.3 连接参数：host、port、user、pass、database怎么填

mysql_mcp_server需要知道“连哪个MySQL实例”以及“用什么身份连”。虽然不同包的参数名可能略有差异，但核心就是下面这张表：

例如：

bash复制mcp-server-mysql --host=127.0.0.1 --port=3306 --user=mcp_ro --pass=your_password --database=test_db

如果你不习惯命令行传参，也可以用环境变量方式：

bash复制export MYSQL_HOST=127.0.0.1
export MYSQL_PORT=3306
export MYSQL_USER=mcp_ro
export MYSQL_PASS=your_password
export MYSQL_DB=test_db
mcp-server-mysql

在CherryStudio里，两种方式都可以用，后面会讲具体怎么填。

3.4 在终端先把MCP服务器跑起来，看到日志再进客户端

请务必先做这一步：在终端里手动启动一次mysql_mcp_server，确认它能正常连接MySQL并保持运行。很多人图省事，装完包就直接去CherryStudio里配，出了问题两头甩锅，最后发现是密码少了一位。

终端启动测试：

bash复制mcp-server-mysql --host=127.0.0.1 --port=3306 --user=mcp_ro --pass=your_password --database=test_db

启动成功的表现是：进程不退出，终端停在一个空白或日志行上，这表示MCP服务器正在等待标准输入上的JSON-RPC请求。如果有Access denied、connect ECONNREFUSED之类的报错，现在就在终端里解决掉，不要拖到CherryStudio里再排查。

终端测试通过之后，按Ctrl+C退出，然后进入下一步。这里多花五分钟，后面至少省一小时。

4. 在CherryStudio里添加mysql_mcp_server：客户端侧完整操作

4.1 找到MCP服务器配置入口

打开CherryStudio，进入设置界面。不同版本的入口位置可能不太一样，但大体路径是：左下角设置图标 → 左侧找到“MCP服务器”或“MCP Servers”选项。有些版本把它放在“服务提供商”配置区域里，有些版本单独成一个菜单项，找不到的话直接在设置顶部的搜索框里搜MCP。

CherryStudio支持两种MCP服务器类型：stdio和streamable http（或sse）。我们要配的本地MySQL服务走的是stdio类型，也就是CherryStudio直接拉起本地进程，通过标准输入输出通信。选择这个类型就行。

4.2 新增stdio类型MCP服务器的字段填写

点击“新增”或“添加MCP服务器”之后，你会看到几个需要填写的字段。我按全局安装的情况来填：

如果你是用命令行参数方式，那参数框里的内容就是把3.3节终端命令中mcp-server-mysql后面的部分照抄过来，前面加-y @benborla/mcp-server-mysql。

如果你不想把密码写在参数里（我更推荐这样），那就把参数简化为：

code复制-y @benborla/mcp-server-mysql

然后在环境变量区域填：

code复制MYSQL_HOST=127.0.0.1
MYSQL_PORT=3306
MYSQL_USER=mcp_ro
MYSQL_PASS=your_password
MYSQL_DB=test_db

这样密码至少不会直接显示在进程参数里，终端进程列表里也不会被一眼看到。

4.3 Windows用户最容易踩的PATH问题，以及两种解决办法

如果你在CherryStudio里保存配置后，发现MCP服务器状态一直“未运行”或者启动失败，日志里出现spawn npx ENOENT或者command not found: npx，那基本就是我2.5节说的PATH问题。

解决办法有两个：

办法一：关闭CherryStudio，重启系统，再打开CherryStudio重试。这个方法有点笨，但确实能解决一部分因为PATH未刷新生效的问题。Node.js刚装完、刚配完环境变量之后尤其有效。

办法二：不用npx，直接用绝对路径。先执行npm root -g拿到全局node_modules路径，再找到包入口文件：

bash复制npm root -g

假设输出是C:\Users\你的用户名\AppData\Roaming\npm\node_modules，那么包的入口大概率在：

code复制C:\Users\你的用户名\AppData\Roaming\npm\node_modules\@benborla\mcp-server-mysql\dist\index.js

然后在CherryStudio的配置里，命令填node，参数填上面这个js文件的绝对路径，再加上3.3节的连接参数。注意node本身也可能有PATH问题，保险起见命令也填绝对路径，比如C:\Program Files\nodejs\node.exe。

用绝对路径之后，PATH问题基本就等于绕过去了。代价是换Node版本或重装包之后路径可能变化，需要重新验证一次。

4.4 保存后怎么看状态，状态异常第一步查什么

配置填完之后保存，CherryStudio会尝试启动MCP服务器。正常状态下，MCP服务器列表里这一项会显示为“运行中”或“已连接”之类的状态。如果状态不对，别急着删配置，先看日志。

CherryStudio的MCP服务器列表里一般会有日志或详情按钮，点开能看到这条MCP服务器的标准输出和错误输出。日志里如果有MCP server running，说明进程起来了；如果有一长串异常堆栈，按堆栈里的关键词去搜。这里想强调一个习惯：看日志的顺序是从上往下，而不是只看最后一行。很多时候最后一行只是结果，真正的原因在前面几行里，比如Access denied、ENOTFOUND、EACCES这种，都是直接指向根因的关键词。

5. 让模型真的把SQL跑起来：从首次对话到确认工具被调用

5.1 第一句测试话术，怎么看它有没有调工具

配置完成并不代表万事大吉，关键要看模型在对话里到底有没有真的调用MCP工具。我的第一个测试话术很简单：“请列出当前MySQL里有哪些数据库，使用mysql工具查询即可。”

发送之后，注意观察三个信号：

一是对话区域会不会出现一个“工具调用”或“MCP调用”的卡片或标记，这是最直接的信号，说明模型已经决定使用工具。二是模型在最终回答里会不会引用查询结果，比如它说“当前共有3个数据库：test_db、blog、shop”，这表示结果确实回来了。三是如果没有调用，看CherryStudio有没有弹工具确认的交互。有的版本会在工具执行前让你确认，有的会直接执行，这个取决于设置。

如果这三个信号一个都没有，那就不是配置问题，而是模型选择问题，进入5.3。

5.2 一次标准查询的完整效果

工具能调用之后，再做一次带条件的查询来验证真正的SQL执行链路。比如我测试时报了一个“test_db”库，我就接着问：“用mysql工具在test_db库里查询users表的前5条数据。”

正常的话，模型会生成一条SQL，比如SELECT * FROM users LIMIT 5，然后把它包装成MCP工具调用。mysql_mcp_server执行完，把结果以JSON或表格形式返回给模型。模型拿到结果后会用自然语言告诉你“users表共有这些字段，前5条数据如下……”，并且在结果区域渲染出一个表格。

这里我建议你对比一下模型自己生成的SQL和数据库实际执行结果。MCP的链路意味着SQL是模型生成的，不是mysql_mcp_server生成的。模型对数据库Schema的理解，取决于它当时能从MCP工具里拿到多少表结构信息。所以如果你的表名比较特殊、字段命名不规范，模型生成SQL时可能猜错。这个问题不是bug，是提示词和工具上下文的问题，后续想让AI更懂你的库，可以在对话里补充表结构说明。

5.3 模型不调用工具怎么办：先分清是“不支持”还是“没提示”

配置正确但模型始终不调用工具，这种问题我在实际使用中碰到过好几次。排查方向有两个。

第一，模型本身是否支持函数调用（function calling）。MCP工具对模型来说本质上是一批函数定义，只有模型API支持工具调用，CherryStudio才能把MCP工具列表传给它。老一点的模型或者某些自定义代理不支持，那MCP工具就永远无法触发。解决办法是换一个支持工具调用的模型，实测下来各家的新模型基本都支持。

第二，模型支持工具调用，但上下文里的指令不够明确。模型在对话里会根据用户意图决定是否用工具，如果你的提问是“你觉得这个数据库该怎么优化”，它可能不会主动去查，而是凭经验回答。这种情况你可以在提示词里直接要求：“如果需要了解数据库结构或数据内容，请使用mysql工具查询。”我测试时发现，把这句话放进系统提示词里，能明显提高工具的主动调用率。

5.4 CherryStudio的日志怎么看，终端日志怎么配合

如果工具确实被调用了，但返回结果异常，比如报错、超时、行列错乱，这就要看日志了。CherryStudio的MCP日志会记录每次调用的请求和响应摘要，能看到模型请求了哪个工具、参数是什么、返回内容是什么。如果你发现请求参数里SQL是undefined，大概率是工具的input schema和模型生成的参数没对上，这种要看是包版本太老还是模型不会用。

终端日志更好用。如果你之前是在终端里手动启动过mysql_mcp_server的，那么你在CherryStudio里启动的MCP服务器进程，其实也可以配合MySQL侧日志来确认SQL是否真正到达。打开MySQL的general_log（只在调试时开，用完就关）：

sql复制SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql_general.log';

然后去对话里再执行一次查询，回头打开日志文件，看有没有对应SQL。这一步能帮你区分“SQL根本没到MySQL”和“SQL到了但执行报错”，定位效率会高很多。

6. 高频报错的完整排查链路：从连接拒绝到权限不足

6.1 Access denied：用户名密码、账号host授权、MySQL8认证插件

这是配置MCP时最高频的报错之一。在MCP日志里会看到类似ER_ACCESS_DENIED_ERROR: Access denied for user 'mcp_ro'@'localhost' (using password: YES)。

先按顺序排查三个点。

第一，密码是不是写错了。这是最常见的原因，把连接参数里的密码复制到MySQL命令行里手动验证一下。第二，账号的host授权是不是覆盖了你连接来源。比如你从127.0.0.1连接，但账号只授权了'mcp_ro'@'localhost'，MySQL对这两个来源的判定是不同的。建议直接把账号建成本机可用的形式：

sql复制CREATE USER 'mcp_ro'@'127.0.0.1' IDENTIFIED BY 'your_password';
GRANT SELECT, SHOW VIEW ON test_db.* TO 'mcp_ro'@'127.0.0.1';
FLUSH PRIVILEGES;

第三，MySQL 8默认的认证插件是caching_sha2_password，有些老版本的Node.js mysql驱动对它的支持不太完善。遇到认证插件问题，可以在建账号时改回mysql_native_password：

sql复制CREATE USER 'mcp_ro'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'your_password';

不过现在主流驱动已经适配了caching_sha2_password，我建议先用这个方案兜底，但不要长期依赖老认证插件。

6.2 ECONNREFUSED和ETIMEDOUT：端口、监听地址、防火墙与Docker

connect ECONNREFUSED 127.0.0.1:3306的意思是：连接被拒绝了，MySQL端口根本没在监听，或者监听地址不对。先确认MySQL服务真的在跑：

Windows下：

bash复制netstat -ano | findstr :3306

Linux/macOS下：

bash复制ss -lntp | grep 3306

如果没有任何输出，说明MySQL服务没有启动，先去启动服务。如果有监听，再看监听地址是不是127.0.0.1，有些MySQL配置了bind-address = 0.0.0.0，有些只绑定了127.0.0.1，如果MCP服务器连的是localhost而MySQL绑定在具体IP上，也可能出现奇怪的问题。最简单的方式是统一用127.0.0.1做连接地址。

ETIMEDOUT则是超时，常见于MySQL跑在Docker容器或另一台机器上。如果你用的是Docker，确认启动时有没有做端口映射，比如-p 3306:3306。还要看防火墙有没有放行3306端口。注意：如果MySQL只在Docker容器内部监听，宿主机上netstat是看不到3306的，只有容器网络才是通的。

6.3 spawn ENOENT和command not found：还是PATH问题

这类报错出现在MCP服务器压根没启动成功的时候。错误信息里有spawn npx ENOENT，说明CherryStudio尝试执行npx但找不到这个可执行文件。

这一节和第4.3节是同一件事的两个侧面。解决办法也不再重复：要么重启系统让PATH生效，要么在配置里填绝对路径。我倾向于直接用绝对路径，因为一劳永逸。把命令从npx改成C:\Program Files\nodejs\node.exe，参数改成包的index.js绝对路径加参数，就再也不会被PATH问题困扰了。

6.4 工具调用失败但日志无信息：用MCP Inspector独立调试

如果消息已经发出，MCP服务器也启动了，但CherryStudio里看不到任何有效错误日志，这时候不要干瞪眼。MCP官方提供了一个调试工具Inspector，可以让你脱离CherryStudio，以纯命令行方式启动MCP服务器并模拟交互。

bash复制npx @modelcontextprotocol/inspector

启动后按提示填入MCP服务器的启动命令和参数，比如：

code复制mcp-server-mysql --host=127.0.0.1 --port=3306 --user=mcp_ro --pass=xxx --database=test_db

Inspector会把MCP协议层的请求响应完全展示出来，你可以看到客户端发的initialize、tools/list、tools/call这些JSON-RPC消息，以及服务器每一条响应的内容。如果在Inspector里能正常调用工具，说明问题出在CherryStudio和MCP进程的交互层；如果在Inspector里也报错，那就回到终端手工启动MCP服务器去排查。

这个工具算是我排查MCP问题的万能钥匙，配合终端手动启动，能覆盖九成以上疑难杂症。

7. 数据库安全必须做在前面：给MCP配一个只读账号

7.1 为什么我强烈不建议在MCP配置里填root

配置过程走到这步，你手上已经有一个能执行SQL的MCP服务器了。如果你图省事，把MySQL的root账号密码填进配置里，那接下来每一句对话都等于把数据库的管理员权限交给了一个AI模型去摆弄。

模型生成的SQL是不可预测的。你让它查数据，它可能生成一条正常的SELECT；但你如果问“帮我把名字重复的用户清理一下”，它可能真的会生成DELETE，万一WHERE条件没写好，结果就是大批量误删。我见过不止一次因为测试MCP时用root账号，随手让AI改了条数据，结果影响线上报表的案例。所以配置MCP，第一步就是给数据库建一个专用账号，权限做到最小。

7.2 创建只读账号的最小权限SQL

这个账号只需要能让模型读取结构、查询数据，不需要插入、更新、删除。MySQL里可以这样建：

sql复制CREATE USER 'mcp_ro'@'127.0.0.1' IDENTIFIED BY 'mcp_ro_strong_password';
GRANT SELECT, SHOW VIEW ON test_db.* TO 'mcp_ro'@'127.0.0.1';
FLUSH PRIVILEGES;

SELECT表示可以查询，SHOW VIEW表示可以查看视图定义，这两个权限足够模型做数据分析。ON test_db.*表示只授权到某一个库，这样即使模型被诱导生成了跨库查询，也会因为权限不足直接报错，而不是真的把别的库的数据拖出来。

如果你后面确实需要让AI执行INSERT、UPDATE，那就按需追加权限，但最好再单独建一个账号区分场景，别把查询和改动混在一起。我自己的习惯是：查询数据用mcp_ro，写数据用mcp_write，只在确认要执行写操作时临时切换配置。

7.3 生产环境还要注意的三件事

如果你不是在本机测试，而是打算把MCP接到一个真正的业务数据库，下面三件事我建议你提前想好。

第一，限制连接数。MCP服务器每次启动都会建立一个MySQL连接，如果你多个会话同时使用，连接数会被撑起来。可以用MySQL的账号约束来控制：

sql复制ALTER USER 'mcp_ro'@'127.0.0.1' WITH MAX_USER_CONNECTIONS 3;

第二，不要让MCP账号拥有所有库的权限。在GRANT语句里精准限定库名和表名，哪怕麻烦一点也值得。表级别授权是MySQL早就支持的能力。

第三，开启审计和慢查询日志。定期检查MCP账号实际执行了哪些SQL，尤其要留意有没有异常的DROP、TRUNCATE、ALTER。如果你的账号权限给得够小，这类SQL应该在数据库层就被拦截，但日志能给你留一条后路，方便追溯问题。

7.4 我现在的操作习惯：先终端后客户端

最后分享一个我的操作顺序：每次新装一个MCP服务器，我都坚持先开终端手动启动，确认没有报错了，再进CherryStudio填配置。这不是多余的仪式感，而是因为终端启动时PATH、环境变量、错误信息都最直观，MCP服务器能否连接MySQL、参数对不对，这一步都能看到最原始的报错。进了CherryStudio再排查，中间隔了一层GUI封装，信息量会被打折。

填配置时，我也习惯把密码放在环境变量里而不是命令行参数里。这样就算你开着进程监视工具看参数列表，也不会直接暴露数据库密码。对于生产环节，我还会考虑用操作系统级的密钥管理或者配置文件来保存敏感信息，这个看个人环境，但原则是：尽量别把密码以明文形式写死在可见的地方。

配置完成之后，你可以试着让模型帮你分析表结构、看看慢查询大致的字段分布，甚至让它写几条查询语句给你参考。MCP的价值就在于把AI从“只能猜”变成“能查”，这个体验一旦打开，后面你就再也回不去了。希望这篇配置记录能让你一次跑通，少走几步我走过的弯路。