很多 .NET 项目做业务开发时，第一步就是往数据库里写数据。C# 连接 MySQL 这件事，我刚入行那段时间也踩了不少坑：明明引了驱动，一运行就报 SSL 连接异常；连接字符串写了一大堆参数，远程服务器偏偏连不上；好不容易连上了，写入中文又变成一堆问号。这些问题的根源大多是驱动版本不匹配、连接字符串配置理解不到位，再加上服务器端授权没打通。这篇就基于我的实际使用经验，把 C# 连接 MySQL 从选型、环境准备、连接字符串拆解到增删改查和问题排查整条链路理一遍。不管你是第一次接触 .NET 项目对接 MySQL，还是已经在项目里用过但被各类连接异常折磨过，这篇内容都能直接当操作手册抄。

1. 动手前先搞清楚：C# 连接 MySQL 的技术选型逻辑

1.1 常见的四种连接方式，各有什么优劣势

很多文章一上来就教你怎么写连接字符串，但我的习惯是先把选型搞清楚。连接 MySQL 这件事，从 .NET 角度来看其实有好几条路，选错了后面维护成本差别很大。

第一条路是直接用官方驱动包，也就是 NuGet 里的 MySql.Data。这是最原始、最通用的方式，所有 ORM 底层最终翻译成 SQL 语句后，几乎都是靠它或类似协议的库去跟 MySQL 服务器通信。优点是对接最底层、代理最少，遇到问题时可排查的范围非常明确，适合写通用数据访问层、写小工具、写定时任务，或者做那种需要精细控制 SQL 的场景。缺点也很明显，就是所有样板代码都要自己写，连接、命令、参数、事务、释放，一步都不能漏。

第二条路是绕开官方包，用社区维护的 MySqlConnector。它在连接池、异步支持、性能细节上做了很多优化，在 .NET Core / .NET 5+ 环境下也越来越常见。如果纯粹从性能角度或者需要更多异步特性，可以优先考虑它，API 风格跟官方包基本一致，切换成本不高。

第三条路是通过 ORM 框架间接连，比如写 EF Core 用 Pomelo.EntityFrameworkCore.MySql，写轻量数据访问用 Dapper。实际上 Dapper 底层还是需要 MySql.Data 或者 MySqlConnector 来提供 ADO.NET 驱动，EF Core 的 MySQL 提供程序也会引入其中一个底层驱动。引入 ORM 的好处是开发效率高，但反过来，如果你连底层连接机制都不理解，出了“连接超时”“连接池耗尽”这类问题，会连日志都看不懂，定位问题特别痛苦。

还有一条路是用 MySQL 官方或者第三方提供的 ODBC 驱动，通过 System.Data.Odbc 操作。我在早期项目里见过这种写法，但现在基本不推荐，多一层 ODBC 包装意味着多一层解析开销，还牵扯驱动在操作系统里的安装和版本兼容问题，部署到生产环境时很容易因为 ODBC 驱动没装好而整个应用起不来。

所以我的建议很直接：用官方 MySql.Data 作为底子和学习路径，把 ADO.NET 这套机制玩明白。后面你用 Dapper 或者 EF Core，再看它们的源码，很多疑惑都能迎刃而解。这篇博文下面的所有示例和排错经验也都基于 MySql.Data 展开。

1.2 版本匹配是第一条铁律，连不上八成是版本问题

C# 连接 MySQL 最隐蔽的坑，其实是版本匹配。我之前帮别人排查过一个问题，驱动用的旧版本，服务器端已经升级到 MySQL 8.0，结果每次连接都抛异常，提示Authentication method 'caching_sha2_password' not supported，字面意思就是驱动不认识新版的认证插件。

MySQL 5.7 时代默认认证插件是mysql_native_password，MySQL 8.0 以后默认改成了caching_sha2_password。旧版驱动在握手阶段只认得老插件，遇到新版服务器就直接拒绝。反过来，新版驱动连接老版本服务器通常没问题，但也会遇到一些函数、特性不兼容的情况，比如某些 SQL 函数在不同版本里的行为有差异，或者驱动里带的新命令在旧服务器上执行报语法错误。

所以动手之前，先查清楚三件事：你的 .NET 运行时版本、你引用的 MySql.Data 版本、你的 MySQL 服务器版本。正常情况下，MySql.Data 8.0.x 可以连接 MySQL 5.7 和 8.0，我个人的经验是优先选择比服务器版本高一个大版本或者等版本的驱动，不要用太老的包。在 NuGet 里安装时，不要无脑点“最新版”，要看你项目的目标框架。比如项目跑在 .NET Framework 4.6.2 上，有的新版本驱动可能会要求更高版本的运行时，装了以后编译能过，运行却报Could not load file or assembly，这种问题最容易让人怀疑人生。

2. 环境准备：引包和开权限，5分钟把基础打好

2.1 NuGet 引包，必须注意的两个细节

在 Visual Studio 里新建一个控制台项目或者类库，接下来就是引入驱动包。最简单的方式是在“解决方案资源管理器”里右键“管理 NuGet 程序包”，搜索 MySql.Data，选对应版本安装。如果喜欢用命令行，直接在“程序包管理器控制台”里执行：

Install-Package MySql.Data

这里有两个细节必须提醒。第一个是包名，平台上有好几个相似的包，比如 MySql.Data 和 MySql.Data.EntityFrameworkCore，前者是纯驱动，后者是早期 EF Core 配套包，现在一般不用了。学习 ADO.NET 基础时只装 MySql.Data 就够了。

第二个细节是项目目标框架。.NET Framework 项目和 .NET Core/.NET 5+ 项目在选择驱动版本时的兼容区间不一样，装完之后建议看一眼“项目依赖”里的程序集版本，确认实际加载的是不是你想用的版本。如果之前装过别的版本，程序集冲突会直接导致运行时异常，这种问题有时候隐蔽到让人以为是代码写错了，实际查一下引用才发现是版本信息对不上。

using MySql.Data.MySqlClient;

代码里加上这一句之后，如果你看到命名空间下不了，通常是包没装成功或者目标框架不兼容，先回过去检查驱动版本。

2.2 服务端 MySQL 这边要放开的三个限制

本地开发时，很多人的 MySQL 就跑在本机，C# 程序也跑在本机，连接一切正常。但一到联调或者部署，程序就要连远程数据库服务器，这时候问题就来了：程序连不上，MySQL 客户端工具却连得上，说明问题不在数据库密码，而在服务器端限制了访问来源。

第一个限制是 bind-address。MySQL 默认可能只监听 127.0.0.1，也就是只允许本机连接。我遇到过一台服务器，别的端口都通了，程序就是连不上，后来登录服务器查看 my.cnf（或者 Windows 下的 my.ini），发现配置里写着bind-address = 127.0.0.1。改成0.0.0.0表示监听所有网卡，然后重启 MySQL 服务，问题才解决。

第二个限制是用户授权的 host 字段。已经创建的本地用户root@localhost只能在本地登录，远程访问会直接报错，提示Host 'xxx.xxx.xxx.xxx' is not allowed to connect to this MySQL server。排查到这一步，就需要新建远程用户或者修改授权。比如在 MySQL 命令行里执行：

CREATE USER 'demo_user'@'%' IDENTIFIED BY 'StrongPassword123!'; GRANT ALL PRIVILEGES ON demo_db.* TO 'demo_user'@'%'; FLUSH PRIVILEGES;

%表示允许任意主机访问，如果你知道程序所在服务器的固定 IP，建议把%换成具体 IP，安全等级会高很多。

第三个限制是防火墙和云安全组。服务器端口 3306 必须对程序所在机器开放。Linux 服务器检查防火墙规则，Windows 服务器检查入站规则，如果是云服务器，还要在控制台的安全组策略里放行 3306。这一步最容易忽略，因为我见过太多人在本地 telnet 测试时总是失败，却不知道云安全组和服务器防火墙是两层东西，只开一层是不够的。

2.3 用命令行客户端验证远程授权是否生效

改完服务器配置别急着写 C# 代码，先在程序所在那台机器上装一个 MySQL 命令行客户端，或者用现成的图形工具做一次远程连接测试。这一步能帮你把“数据库配置问题”和“代码问题”这两类问题彻底隔离开。

mysql -h 服务器IP -P 3306 -u demo_user -p

如果命令行能连上，说明服务器端授权、端口、防火墙都已经通了，接下来 C# 连不上就纯粹是连接字符串或者驱动的问题，排错范围立刻缩小一半。如果命令行连不上，先别碰代码，回头检查上面提到的三个限制。

3. 连接字符串：从翻车到稳定的完整拆解

3.1 连接字符串每个参数讲明白

连接字符串是整个 C# 连接 MySQL 操作里最核心的东西，很多人只会填写服务器地址和密码，其他参数一概不动，结果就是在不同环境里行为不一致，时而稳定时而抽风。我在项目里常用的一个完整连接字符串长这样：

Server=192.168.1.100;Port=3306;Database=demo_db;Uid=demo_user;Pwd=YourPassword;Charset=utf8mb4;SslMode=None;Pooling=True;MinimumPoolSize=5;Maximum Pool Size=100;Connection Timeout=30;Default Command Timeout=30;

逐个拆开看，每一个参数都有讲究。

Server指定 MySQL 服务器地址，这里有个容易翻车的小细节：写localhost时，部分情况下程序会去解析成 IPv6 的::1，而 MySQL 服务没监听这个地址，于是连接失败。写实际 IP 比如127.0.0.1或者服务器的内网/公网 IP，通常最稳。

Port是端口号，默认 3306，如果你改了端口，这里必须同步修改。Database是初始要连接的库名，可以不写，但连接后再切换库就是多一次交互，建议直接写默认库。

Uid和Pwd是用户名和密码，这个不用多说。需要提醒的是密码里有特殊字符时，比如分号、井号，要在连接字符串里转义或者用代码拼接配置的方式，我遇到过密码里带#导致后面的参数全部被注释掉的情况，排查半天才发现是配置解析的问题。

Charset要特别注意。开发环境里没有中文问题不代表生产环境没问题，建议统一写成utf8mb4，这个字符集可以覆盖绝大多数符号。很多老项目写的是utf8，大多数时候没问题，但碰到生僻字或者 emoji 符号就会出现数据丢失，或者写入报Incorrect string value错误。

SslMode的坑也很多。官方驱动从较新版本开始，默认对连接启用 SSL 校验，如果你的 MySQL 服务器没有配置有效的 SSL 证书，连接时就会报 SSL 相关异常。本地开发或内网环境，明确没有 SSL 加密要求时，设置SslMode=None可以跳过这一层，程序就安静了。生产环境如果走公网传输，最好还是正经配置好证书，把 SslMode 设成Required或者VerifyFull，别图省事裸奔。

3.2 连接池参数没配置好，高并发必翻车

连接字符串里真正影响高并发稳定性的是池参数。ADO.NET 驱动的连接池默认是开启的，意思是你的程序每次Open()一个连接，用完Close()之后，驱动不会真的把 TCP 连接断开，而是把这个连接放回池里，下次再Open()时优先从池里拿现成的连接。这样省去了反复建立 TCP 连接和做 MySQL 握手认证的开销。

连接池有几个参数值得单独说。Pooling=True是开启，一般不需要额外设置；关键是Minimum Pool Size和Maximum Pool Size。Maximum Pool Size是池里最多能同时放多少连接，默认通常是 100，如果并发请求数超过这个值，驱动会等待有连接释放，超时后抛出Timeout expired异常。我之前遇到过一个线上小服务，突发流量一来就报超时，很多同事怀疑是网络问题，后来把连接字符串里的Maximum Pool Size调大、同时优化了业务里连接释放的逻辑，问题才缓解。

Connection Lifetime和Connection Reset可能很多人没注意过。MySQL 服务器或者中间的网络设备（比如某些对空闲连接有回收机制的负载均衡）会在空闲一段时间后断开连接，池里的连接就成了“坏连接”。下一次程序拿到这个连接去执行 SQL，可能直接抛错。设置合适的Connection Lifetime，比如 60 秒，让驱动定期重建连接，能规避一部分这种偶发问题。

还有一点非常重要：Close()方法不是真的关闭连接，而是把连接还回池里。很多初学者以为调用Close()就万事大吉了，其实只要连接字符串不变，池里的连接就会保持复用。所以一定要保证每次用完连接都尽快关闭，最好是配合using语句块，让连接对象在超出作用域后自动释放。

3.3 先写一段代码验证连接是否通

配好连接字符串后，先不要一上来就写业务 SQL，我习惯先跑这么一小段代码：

using MySql.Data.MySqlClient; string connectionString = "Server=192.168.1.100;Port=3306;Database=demo_db;Uid=demo_user;Pwd=YourPassword;Charset=utf8mb4;SslMode=None;"; using (var conn = new MySqlConnection(connectionString)) { conn.Open(); Console.WriteLine("连接成功，状态：" + conn.State); } catch (MySqlException ex) { Console.WriteLine("连接失败：" + ex.Message); }

这段代码干的事只有一件：测试握手和认证能否通过。如果这一关过了，后面 SQL 层面的问题就不再是“连不上”的问题，而是命令和查询的问题，排错范围一下就清晰了。

4. 核心实操：增删改查与事务的完整实现

4.1 查询：DataReader 与 DataTable 怎么选

连接打通以后，最常见的操作就是查询。用 MySqlCommand 执行查询，结果集可以用两种方式访问，一种是流式读取的 MySqlDataReader，一种是内存驻留的 DataTable。

流式读取适合数据量大、逐行处理的场景，它不会一次性把所有记录加载到内存。举个例子，导出一张几十万行数据的表时，如果用 DataTable，内存会被瞬间拉满，程序运行期间经常报内存不足；用 DataReader，读一行处理一行，内存占用稳定得多。

using (var conn = new MySqlConnection(connectionString)) using (var cmd = new MySqlCommand("SELECT id, name, create_time FROM users WHERE status = @status", conn)) { cmd.Parameters.AddWithValue("@status", 1); conn.Open(); using (var reader = cmd.ExecuteReader()) { while (reader.Read()) { int id = reader.GetInt32("id"); string name = reader.GetString("name"); DateTime createTime = reader.GetDateTime("create_time"); Console.WriteLine($"{id} | {name} | {createTime}"); } } }

这里有几个细节值得注意。第一个是AddWithValue，它会自动推断参数类型，但有时候会推断错，比如给整数类型字段传入字符串类型，MySQL 端可能发生隐式转换，影响索引命中。更稳妥的做法是用new MySqlParameter("@status", MySqlDbType.Int32) { Value = 1 }明确指定类型。第二个是在使用 DataReader 期间连接必须保持打开状态，所以务必将整个读取过程放在using块内，否则连接提前关闭会导致后续读取直接抛异常。

如果数据量不大、只是需要一次性绑到界面或者转成 JSON 返回接口，用 MySqlDataAdapter 填充 DataTable 更省事：

using (var conn = new MySqlConnection(connectionString)) using (var adapter = new MySqlDataAdapter("SELECT * FROM users", conn)) { DataTable dt = new DataTable(); adapter.Fill(dt); }

Fill 方法内部会自动打开和关闭连接，不用你手写 Open。这种方式对行数有要求，我一般建议放一张表的全量数据控制在几万行以内，再大就考虑分页。

4.2 参数化写入，防注入是底线中的底线

写入、更新、删除操作都是执行ExecuteNonQuery()。这里我要反复强调一件事：永远别用字符串拼接去组装 SQL。字符串拼接注入风险不是个别现象，是真实出现过无数次的翻车原因。假设你写了一句"SELECT * FROM users WHERE name = '" + name + "'"，用户传入name的值为' OR '1'='1，整条 SQL 就变成了SELECT * FROM users WHERE name = '' OR '1'='1'，结果会返回整张表。

正确姿势是参数化查询：

using (var conn = new MySqlConnection(connectionString)) using (var cmd = new MySqlCommand("INSERT INTO users (name, email, age) VALUES (@name, @email, @age)", conn)) { cmd.Parameters.Add("@name", MySqlDbType.VarChar, 50).Value = "张三"; cmd.Parameters.Add("@email", MySqlDbType.VarChar, 100).Value = "zhangsan@example.com"; cmd.Parameters.Add("@age", MySqlDbType.Int32).Value = 25; conn.Open(); int rows = cmd.ExecuteNonQuery(); Console.WriteLine($"影响行数：{rows}"); }

参数化的本质是让驱动把参数值单独传给服务器，服务器再对参数值做绑定，也就是参数值永远不会被当成 SQL 语句的一部分来解析。用户在界面上输入什么，就是什么，哪怕里面塞了DROP TABLE，也只是一段普通的字段值，不会产生任何危害。这个观念一定要刻在骨子里。

更新和删除的写法跟插入基本一致：

using (var conn = new MySqlConnection(connectionString)) using (var cmd = new MySqlCommand("UPDATE users SET name = @name, age = @age WHERE id = @id", conn)) { cmd.Parameters.AddWithValue("@name", "李四"); cmd.Parameters.AddWithValue("@age", 30); cmd.Parameters.AddWithValue("@id", 1001); conn.Open(); cmd.ExecuteNonQuery(); }

还有一点建议所有项目都做：增删改操作返回的是受影响行数，最好判断一下rows是否等于预期值。比如删除操作，本意删一条记录，结果条件写错删了十条，如果没有行数判断，这条异常行为就会悄悄溜走。

4.3 多 SQL 用事务包起来，别让数据写一半

业务里经常会出现需要同时更新多张表的情况，比如订单表加一条记录，库存表减一个数。这两个操作必须同时成功或同时失败，否则就会出现库存扣了但订单没生成，或者订单生成了但库存没扣的脏数据。这时候就要用事务。

using (var conn = new MySqlConnection(connectionString)) { conn.Open(); using (var transaction = conn.BeginTransaction()) { try { using (var cmd1 = new MySqlCommand("INSERT INTO orders (order_no, user_id) VALUES (@orderNo, @userId)", conn, transaction)) { cmd1.Parameters.AddWithValue("@orderNo", "20250101001"); cmd1.Parameters.AddWithValue("@userId", 88); cmd1.ExecuteNonQuery(); } using (var cmd2 = new MySqlCommand("UPDATE inventory SET stock = stock - 1 WHERE product_id = @productId", conn, transaction)) { cmd2.Parameters.AddWithValue("@productId", 5); cmd2.ExecuteNonQuery(); } transaction.Commit(); } catch (Exception ex) { transaction.Rollback(); Console.WriteLine("事务已回滚：" + ex.Message); } } }

这段代码里，两个命令用的都是同一个连接对象和同一个事务对象，这是关键所在。如果你在事务中途新建了另一个连接，事务根本不作用于那上面的命令，你可能会以为两个操作都在事务里，实际上第二个操作处于“裸奔”状态。我之前接过一次现场排查，业务代码里原来的写法是在事务内部又自己new MySqlConnection，结果关于数据不一致的问题就一直没有被彻底解决。所以在事务代码里，一个事务下的所有命令，必须绑定同一个连接。

事务层级也别搞得太深，除非特殊业务，否则尽量保持事务短小果断。长事务会持有行锁和表锁，拖垮并发，让整个库的吞吐量下降。操作完成后立刻Commit，异常了立刻Rollback。

5. 常见问题与排查技巧实录

5.1 最常见的四类连接报错速查表

把网上各种求助帖和实际接到的问题汇总一下，连接 MySQL 的高频报错基本可以分成下面四类：

Access denied for user 'xxx'@'yyy'这类错误里，@后面那部分很关键。它告诉你服务器是从哪个 IP 看到的你，以及这个 IP 是否有权限。如果显示的是'demo_user'@'localhost'而程序是远程连接，那问题就是授权 host 不对。直接用命令行客户端登录服务器 MySQL，执行SELECT user, host FROM mysql.user;看看用户列表，心里就有数了。

Unable to connect这条比较粗，只告诉你找不到任何可用的 MySQL 主机。先不问代码，直接在客户端机器上执行telnet 192.168.1.100 3306，如果提示连接失败，那就去查端口、防火墙、MySQL 是否在监听。这一步能省去很多无意义的代码调试。

5.2 中文乱码与字符集核对

C# 连接 MySQL 后写入中文变成问号，是一个几乎绕不开的历史问题。这种现象通常是连接字符串里没指定字符集，或者服务器端、数据库表、连接层三个地方的字符集不一致。一个链路上的任何一环用了 latin1 或旧的 utf8，都会出乱码。

排查时可以按顺序执行下面几条命令：

SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'character_set_database';

然后查看具体表的字符集：

SHOW TABLE STATUS LIKE 'users';

靠谱的做法是全局统一：MySQL 服务端配置设为utf8mb4，创建数据库时指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，连接字符串里写Charset=utf8mb4。三层保持同一个字符集，乱码概率基本归零。再补充一句，连接字符串里的Charset参数在部分旧版本驱动中优先级很高，写错了反而会覆盖客户端期望的字符集，所以一定要确认驱动版本支持的写法。

5.3 连接池与空闲连接导致偶发异常的根治

还有一种表现很诡异：程序运行几小时甚至几天都正常，突然请求时报错，重启之后又恢复。这种偶发问题十有八九是空闲连接被服务端或者中间网络设备回收导致的。

MySQL 默认有一个wait_timeout，约 8 小时，超过这个时间的空闲连接会被服务端关闭。但客户端连接池不知道这件事，它以为队列里那个连接还是好的，下一次从池里取出来直接用，服务器早就把这条 TCP 连接清理掉了，于是程序就抛异常。我之前接手过一个报表服务，每隔 5 分钟跑一次定时任务，数据源来自 MySQL，部署到生产环境后运行到凌晨必挂一次，查了很久才发现是夜间空闲期内连接被服务端回收，而池里还存着失效连接。

对抗这个问题有几个手段。一是让程序在每次任务前重新连接而不是长期复用同一个连接；二是设置合理的Connection Lifetime，比如 60 秒，让驱动在连接生命周期到期后自动清掉重建；三是在代码里捕获异常后执行重试，重试时重新 Open 连接。这几种方案可以在项目里叠加使用，不能说根治百分之百，但实战中能解决绝大多数间歇性故障。

5.4 排查思路：从报错信息反推配置

很多朋友一看到长串异常日志就紧张，感觉无从下手。我的经验是：不要从代码开始查，先拆异常信息。把异常消息里的关键词取出来，比如Timeout expired、Access denied、SSL、Command Timeout，然后再去对应排查。

举一个实际例子。有一次测试环境报Timeout expired，第一反应以为是网络波动，后来发现是连接字符串里没有设置Maximum Pool Size，默认 100 的连接池被高并发请求打满，新请求都在排队等空闲连接，最后等不及就超时了。我把池上限调高，同时把连接释放代码改为统一的using，问题就解决了。

再举一个例子，某人连接本机数据库一直报 SSL 相关错误，但命令行工具连接正常。仔细看连接字符串，发现SslMode没写，默认走 Preferred 模式，本机 MySQL 没有配置可用的 SSL 证书。设置SslMode=None后，程序连接立刻正常。这类问题排查起来逻辑非常清楚，先看异常字面意思，再回去看连接字符串对应参数，基本都能定位。

6. 写在最后：一点个人经验

6.1 连接配置不要散落在代码各处

我见过不少项目，每个类库都自己写一套连接字符串，有的是常量写在代码里，有的硬编码在多个方法里，改数据库密码时需要全局搜索替换。这个习惯非常危险，因为 MySQL 的连接字符串参数很多，某个文件的写法跟别的地方不一样，就会成为一个隐藏炸弹。后来在项目里我把连接字符串统一收敛到配置文件或者配置中心，代码里只读取一个配置项，改密码、调连接池参数都不需要动业务代码。

6.2 日志里务必记录连接信息和异常细节

做调试时，情报丰富度决定排错速度。连接失败的异常信息一定要完整记录，不仅记错误消息，还要把服务器地址、端口、配置的用户名附带记录下来。有一次我在现场排查一个连接问题，看了日志才发现，程序读的配置来自一份旧文件，里面还是几年前的测试库地址，跟当前代码里看到的配置完全不是同一个来源。没有日志，这种问题真的很难定位。建议代码里的错误日志多打印一层连接信息（不含密码），成本不高，关键时刻能救命。

C# 连接 MySQL 说到底是驱动版本、连接字符串、权限链路三层问题的博弈。把这三层各自理顺，连接、增删改查、事务这些基础能力就都能稳了。希望这篇从实际项目里磨出来的经验能帮你少走点弯路。