1. Cursor 里让 AI 直接读 MySQL 表结构，为什么总卡在连接这一步
很多人用 Cursor 写后端代码时都会遇到同一个尴尬：AI 能帮你生成 Controller、Service、Mapper，但它不知道你数据库里到底有哪些表、字段类型是什么、索引怎么建的。结果就是它一本正经地编字段名，你复制粘贴跑一遍，报错Unknown column 'xxx' in 'field list'，然后来回改。Cursor 使用 MCP 连接 MySQL 数据库这件事，本质就是给 AI 装一个"能查库"的手，让它建表、插数据、读结构之前先看一眼真实情况。
MCP 全称 Model Context Protocol，你可以把它理解成 Cursor 和外部工具之间的一个标准插座。MySQL 是一个外部工具，MCP Server 就是那个转接头，Cursor 通过它把"查表""建表""执行 SQL"这些能力暴露给模型。没有 MCP 的时候，你只能把表结构手动贴进对话里；有了 MCP，模型可以自己调用工具去读information_schema，拿到真实的列定义再写代码。
这篇聚焦两种连接路径：本地 socket/端口直连，和远程 URL 方式。前者适合你本机装了 MySQL、开发环境就在 localhost 的场景；后者适合云端数据库、团队共享实例、或者你不想在本地暴露账号密码的情况。两种方式我都会给出可复制的配置片段，并且用一条查询验证连接是否真的生效。适合谁看：正在用 Cursor 做后端开发、手里有 MySQL 实例、想让 AI 少编字段名的同学。下面所有配置里的 Base URL、Key、Model ID 三件套，我会在接入环节统一说明，避免你东拼西凑。
先说清楚一个前提：MCP 让 AI 能读写数据库，这既是能力也是风险。生产库千万别直接挂上去让模型随便执行 DDL。我的做法是本地开发库随便连，云端库只给只读账号或者限定 schema。这个边界你自己心里要有数。
2. TaoToken 前置准备：Base URL、API Key 与 Model ID 三件套怎么拿
在配 MySQL MCP 之前，得先把 Cursor 里的模型通道打通。Cursor 本身支持自定义模型接入，你需要准备三样东西：Base URL、API Key、Model ID。这三件套缺一不可，很多人配 MCP 失败其实不是 MCP 的问题，是模型通道根本没通。
Base URL 填https://taotoken.net/api，注意这里不加任何多余路径。API Key 去控制台生成，路径是 console 页面里的 api-keys 管理。Model ID 根据你用的模型填，比如你要用 Claude 系列做代码生成，就填对应的模型标识。这三个值在 Cursor 的模型设置里对应填好，保存后先确认普通对话能通，再去折腾 MCP。
我试过的一个坑：有人把 Base URL 填成了带/v1或者带具体 endpoint 的地址，结果请求 404。正确做法就是干净的https://taotoken.net/api，后面的路径由 Cursor 自己拼。API Key 生成后记得复制完整，只显示一次，丢了就重新生成。
如果你还没生成 Key，可以走这个流程：打开控制台，找到 API Keys 菜单，点新建，命名随便写比如cursor-mysql-dev，生成后立刻复制。这个 Key 后面在 MCP 配置里可能用不到（MCP 连的是 MySQL，不是模型），但 Cursor 的模型通道必须先用它跑通，否则你 MCP 配好了，模型那边 401，一样用不了。
模型通道验证方法很简单：在 Cursor 里新建一个对话，问一句"你好"，能正常回复就说明三件套没问题。如果报 401，检查 Key 是否复制完整、有没有多余空格；如果报 model not found，检查 Model ID 拼写。这一步过了，再进入 MCP 配置。
顺便说下 Coding Plan 的场景：如果你打算长期用 Cursor 做 Agent 式编码，频繁调用模型，可以考虑 Coding Plan 这种按周期计费的方式，比单次调用更划算。接入文档里有详细的参数说明，遇到不确定的字段先去文档查，别猜。
3. 可复制配置：本地 socket/端口 与 远程 URL 两种 MCP 写法
这一节是核心，两种方式的配置文件我都给全。Cursor 的 MCP 配置入口在设置里的 MCP 面板，或者直接编辑配置文件。配置文件通常是 JSON 格式，路径在 Cursor 的用户配置目录下，Windows 和 macOS 位置不同，但你在 MCP 面板点"Add"它会帮你定位。
先说本地方式。本地 MySQL 跑在 127.0.0.1:3306，用 stdio 类型的 MCP Server，通过 npx 拉起。配置片段如下：
{ "mcpServers": { "mysql-local": { "type": "stdio", "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-mysql" ], "env": { "MYSQL_HOST": "127.0.0.1", "MYSQL_PORT": "3306", "MYSQL_USER": "root", "MYSQL_PASSWORD": "你的本地密码", "MYSQL_DATABASE": "your_dev_db" } } } }这里的关键是env里的环境变量模板。MYSQL_HOST本地就填127.0.0.1，如果你用 socket 连接，有些 server 支持MYSQL_SOCKET变量指向/tmp/mysql.sock或/var/run/mysqld/mysqld.sock，具体看 server 实现。端口默认 3306，改过就填改后的。密码别写错，这是最常见的失败原因。
再说远程 URL 方式。云端数据库或者你通过 URL 暴露的实例，用这种方式。配置片段：
{ "mcpServers": { "mysql-remote": { "type": "stdio", "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-mysql" ], "env": { "MYSQL_URL": "mysql://user:password@your-host:3306/your_db", "MYSQL_SSL": "true" } } } }URL 格式是mysql://用户名:密码@主机:端口/数据库名。如果密码里有特殊字符比如@或#，要做 URL 编码，否则解析会出错。云端库一般要求 SSL，所以加MYSQL_SSL: "true"。有些托管 MySQL 会给一个完整的连接串，你直接粘到MYSQL_URL里就行。
两种方式对比一下：
| 维度 | 本地 socket/端口 | 远程 URL |
|---|---|---|
| 适用场景 | 本机开发库 | 云端/共享实例 |
| 配置复杂度 | 低，填 host/port 即可 | 中，注意 URL 编码和 SSL |
| 安全性 | 账号密码在本地 | 建议用只读账号 |
| 网络要求 | 无 | 需要能访问远程主机 |
配置写完后保存，Cursor 的 MCP 面板里应该能看到 server 状态。绿灯表示连上了，红点表示失败。这里有个高频问题：npx 第一次拉包会慢，面板可能先红后绿，等几秒刷新一下。如果一直红，看下一节的排错。
另外提一句，如果你用的是 Smithery 这类平台生成的配置，它会给你一个带--key和--profile的 args，那种是平台托管的 MCP，本质也是 stdio，只是连接信息在平台侧配置好了。用哪种都行，关键是搞清楚数据流向：你的 SQL 请求经过谁、账号权限多大。
4. 验证请求：用一条查询确认 MCP 真的连上了
配置保存、面板变绿之后，别急着让 AI 建表。先用一条最简单的查询验证链路。在 Cursor 对话里输入：
请用 MySQL MCP 执行：SELECT VERSION();如果 MCP 正常工作，模型会调用工具，返回类似8.0.35的版本号。这一步成功，说明连接、认证、权限都通了。如果模型说"我没有可用的 MySQL 工具"，说明 MCP server 没被 Cursor 识别，回去检查配置格式和面板状态。
第二步验证读表结构：
请列出当前数据库所有表名，并给出其中一张表的字段定义。正常返回会包含information_schema.tables的查询结果。这一步能过，说明 AI 已经能看到你的真实表结构了，后面让它写代码就不会瞎编字段。
第三步验证写能力（本地库做，生产库跳过）：
请创建一张测试表 t_mcp_check，包含 id 主键、name 字符串、created_at 时间戳，然后插入一条数据并查出来。成功的话你会看到建表语句执行、插入成功、查询返回一行。到这里，Cursor 使用 MCP 连接 MySQL 的完整链路就验证完了。
实测下来，最容易出问题的是权限。只读账号执行建表会报Access denied，这不是 MCP 的错，是账号权限不够。云端库联调时，建议单独开一个开发账号，给SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER权限，别用 root。
验证通过后，你可以让 AI 做更复杂的事，比如"根据这张表结构生成对应的 Go struct 和 CRUD 接口"。因为它现在读的是真实 schema，生成的代码字段类型、命名都能对上，省掉大量手动对齐的时间。
5. 常见报错排查：401、local proxy failed、reading choices、OAuth 逐个拆
配 MCP 的过程里，报错基本集中在几类。我按真实遇到的顺序拆一遍。
401 Unauthorized：这个通常不是 MySQL 的错，是 Cursor 模型通道的 Key 问题。检查 Base URL 是不是https://taotoken.net/api，Key 有没有复制完整，有没有多余空格。如果 MCP 面板绿了但对话报 401，就是模型通道的事，跟 MySQL 无关。
local proxy failed / connection refused：MCP server 起不来。常见原因是 npx 拉包失败、Node 版本太低、或者 host/port 填错。先在终端手动跑一遍npx -y @modelcontextprotocol/server-mysql，看报什么错。如果是ECONNREFUSED，确认 MySQL 服务在跑、端口对、防火墙没拦。本地 socket 方式还要确认 socket 文件路径存在。
reading 'choices' of undefined：这个报错一般出现在模型返回结构异常时，多半是 Model ID 填错或者模型通道返回了非预期格式。检查 Model ID 拼写，确认用的模型在 TaoToken 侧是支持的。有时候换个模型试一下就能定位。
OAuth 相关报错：如果你用的是需要 OAuth 的托管 MCP 平台，token 过期会报这个。重新在平台侧授权，或者换成 stdio 直连方式绕开。OAuth 流程对本地开发来说偏重，能直连就直连。
MCP 面板红点、要反复刷新：这是 Cursor 本身的已知体验问题。server 进程偶尔会挂，面板状态没同步。解决办法：在 MCP 面板点一下重启 server，或者关掉 Cursor 重开。如果频繁发生，检查是不是 npx 每次都在重新拉包导致启动慢，可以考虑全局安装 server 包，把 command 从npx改成直接指向安装后的可执行文件，启动会快很多，红点也少。
建表报语法错：模型生成的 DDL 可能带了不兼容的语法，比如用了 MySQL 8 才支持的表达式默认值，而你库是 5.7。让 AI 先查SELECT VERSION()再生成，或者明确告诉它目标版本。
排查的核心思路：先分层，是模型通道的问题还是 MCP 的问题还是 MySQL 的问题。模型通道看 401 和 choices 报错，MCP 看面板状态和 server 日志，MySQL 看连接和权限报错。分层之后，问题范围就小很多。
6. 把 MCP 接进日常开发流：从建表到生成代码的完整动作
链路通了之后，真正提升效率的是把它接进日常流程。我的习惯是：新需求来了，先让 AI 通过 MCP 读一遍相关表结构，再让它生成代码。这样它写的 struct 字段和数据库对得上，省掉手动核对。
具体动作：在 Cursor 里开一个对话，先让它执行SHOW TABLES，确认库里有啥；然后针对目标表执行SHOW CREATE TABLE xxx，拿到完整 DDL；接着让它"根据这个 DDL 生成 Go 的 model 和 repository 层"。因为 DDL 是真实读出来的，生成的代码质量比手贴高很多。
如果你要做数据库变更，也可以让 AI 先生成 migration 脚本，你 review 后再通过 MCP 执行。注意生产库别让模型直接执行，生成脚本人工过一遍更稳。
关于长期使用，如果你打算把 Cursor 当主力编码工具，频繁调用模型做 Agent 任务，Coding Plan 这种模式值得了解一下，接入文档里有说明。模型对话页面可以用来快速验证某个模型是否适合你的场景，不用每次都开 Cursor。
最后说个实用技巧：把常用的 MCP 查询封装成对话模板，比如"读表结构生成 CRUD"存成一个 prompt，每次换表名就行。这样 Cursor 使用 MCP 连接 MySQL 的收益会随着你用得越多越明显。数据库联调这件事，从"手动贴结构"变成"AI 自己看"，省下的时间累积起来很可观。
