简介MySql.Data 8.0.13 x86 组件包是 MySQL 官方 .NET 连接器面向使用 C#、VB.NET 等语言的桌面与 Web 开发者用于解决 .NET 应用连接 MySQL 数据库时缺少驱动或版本不匹配的问题适用范围涵盖基础 ADO.NET 操作、Entity Framework 6 及 Entity Framework Core 等数据访问场景。包内共 12 个文件包含 6 个 DLL 程序集、5 个 XML 注释文档和 1 个 installstate 安装状态记录文件压缩包约 560KB。其中 MySql.Data.dll 提供核心连接器MySql.Data.EntityFramework.dll 与 MySQL.Data.EntityFrameworkCore.Design.dll 分别承担 EF6 与 EF Core 的适配及设计时支持MySql.Web.dll 用于 ASP.NET 会话状态等 Web 集成XML 文件可在 Visual Studio 中提供 API 注解installstate 用于确认安装信息。此外还附带 Google.Protobuf.dll补齐 MySQL 8 兼容性所需的序列化依赖。该包已有 1429 人学习/下载体积小巧、引用便捷适合在 x86 目标平台或需要精确控制引用集的 .NET 项目中直接使用。1. MySql.Data.dll 8.0.13 x86一个程序集文件引发的兼容性连锁反应MySql.Data.dll 8.0.13 x86 是 MySQL Connector/NET 8.0.13 在 32 位进程里的核心连接驱动。文件不大但它一翻车整个项目就起不来。最常见的现场是64 位 Windows 上跑旧版 WinForm加入 MySQL 支持后启动就抛 BadImageFormatException查到最后往往是 AnyCPU 项目以 64 位进程运行又混入了 32 位 COM 组件CLR 无法跨位数加载程序集。这个 x86 版本解决的正是这类平台冲突。拿到它把项目平台目标锁到 x86再放进 bin 目录连接链路才算真正闭环。适合三类人维护 32 位 COM 插件或 Office 加载项的老项目从 5.6/5.7 迁到 MySQL 8.0 的升级场景以及被版本冲突和位数报错反复折腾、想一次查清根因的人。2. 架构选型与依赖核对先搞清 x86 版本解决的是哪类问题2.1 AnyCPU 程序集为什么在 64 位机器上翻车先说结论在 .NET Framework 里AnyCPU 编译出来的程序集放到 64 位 Windows 上默认就是以 64 位进程运行的只有放到 32 位系统上才会退化成 32 位。.NET 4.5 之后多了个 Prefer32Bit 选项能在 64 位系统上把 AnyCPU 程序集按 32 位跑但这个开关只对 AnyCPU 有效对已经标记为 x86 或 x64 的程序集完全不生效。进程位数一旦在启动时定下来后面所有托管程序集、原生 DLL、COM 组件的加载都按这个位数来。CLR 不会因为你某个依赖是 32 位的就把进程切成 32 位它只会在加载到不匹配的模块时直接抛 BadImageFormatException。所以MySql.Data.dll 是托管程序集放哪儿都一样这个想法是错的——程序集本身是 IL但进程按 64 位跑时JIT 的代码路径、指针宽度、GC 布局全是 64 位语义这时候混入 32 位原生组件整个加载链就断了。真正需要 x86 版 MySql.Data.dll 的场景有几种项目里引用了 32 位原生 DLL通过 COM 互操作调用了 32 位组件或者目标机器本来就是 32 位 Windows。还有一种更隐蔽的情况你在 Visual Studio 里调试时走了 64 位宿主机进程但部署后目标机器是 32 位导致开发环境正常、生产环境爆炸。用 x86 版 MySql.Data.dll等于把托管加载链显式钉死在 32 位排错方向一下子收敛。2.2 8.0.13 的版本边界兼容什么、依赖什么8.0.13 对应的是 MySQL Connector/NET 8.0.13 这个发布线不是 6.x 的老连接器。它跟 MySQL Server 5.7 和 8.0 都能配合认证插件上同时支持老的 mysql_native_password 和 8.0 默认的 caching_sha2_password——这一点是很多老项目升级时没注意到的用 6.9.x 去连 MySQL 8.0会因为不认识 caching_sha2_password 直接报Authentication method not supported。维度8.0.13 的支持情况服务器版本MySQL Server 5.7 / 8.0认证插件mysql_native_password、caching_sha2_password传输加密TLS 1.2字符集utf8、utf8mb4 全量支持.NET 目标.NET Framework 4.5.2.NET Core 2.0这里要区分托管依赖和原生依赖。MySql.Data.dll 本体是纯托管程序集不需要 VC 运行库但官方 MSI 完整安装包里还带工具链和原生组件这部分走的是 WinSxS 并行清单。如果你在加载日志里看到 microsoft.vc80.mfc、processorarchitecturex86、typewin32、version8.0.50608.0 这类条目那是原生组件在要求 VC 2005 运行库的 x86 版本不是 MySql.Data.dll 的托管部分引起的。排查时别把这两类依赖混在一起否则会对着一个根本不存在的问题找半天。2.3 裸 DLL 与 NuGet 包的差别以及文件名陷阱用 NuGet 安装 Connector/NET拉回来的是一个程序集集合核心的 MySql.Data.dllEF6 用的 MySql.Data.EntityFramework.dllEF Core 用的 MySql.Data.EntityFrameworkCore.dll还有 MySql.Web.dll 之类。裸 DLL 只有一个文件干净但要自己处理强名称验证和绑定重定向。我见过不少人搜 mysql.data.d、MySql.Data.E、MySQL.Data.E 这些关键词结果下回来的是 MySql.Data.EntityFramework.dll 或 MySql.Data.EntityFrameworkCore.dll。这俩是 ORM 适配器壳不是完整连接器直接引用到项目里会缺一堆类型。下载后第一件事是核对程序集标识MySql.Data, Version8.0.13.0, Cultureneutral, PublicKeyTokenc5687fc88969c44d。公钥令牌不对文件就有问题。3. 引用与部署把 x86 版 MySql.Data.dll 装进项目的三条路径3.1 Visual Studio 项目引用与 PlatformTarget 设置拿到 DLL 后最常见的落地方式是项目直接引用。在 Visual Studio 里右键引用浏览到 DLL 所在目录选中确认。但这一步做完还不够必须检查项目平台目标。如果项目是 AnyCPU在 64 位机器上调试时就可能踩 2.1 里说的坑。直接在 csproj 里确认这两个节点PropertyGroup Condition$(Configuration)|$(Platform) Debug|AnyCPU PlatformTargetx86/PlatformTarget Prefer32Bitfalse/Prefer32Bit /PropertyGroup PropertyGroup Condition$(Configuration)|$(Platform) Release|AnyCPU PlatformTargetx86/PlatformTarget Prefer32Bitfalse/Prefer32Bit /PropertyGroupPlatformTarget 设为 x86CLR 启动时就会把进程按 32 位拉起MySql.Data.dll 的 x86 版本才能在同一个进程里正常加载。Prefer32Bit 在 x86 平台目标下没有实际作用留着 false 只是防止以后改成 AnyCPU 时行为漂移。注意 Debug 和 Release 两个配置要一起改只改一个的话换个配置编译又回到 64 位进程报错会像灵异事件一样时好时坏。还有一点容易被忽略项目里如果有 C/CLI 项目或 COM 引用这些项目的平台目标也要跟着锁 x86。光改主项目引用的原生项目还是 x64构建时能过运行时会炸。3.2 GAC 注册与强名称验证如果你的程序要装到多台机器而每台机器上又有多个应用共享同一个版本的 MySql.Data.dll可以考虑装进 GAC。但这不是默认选项GAC 里的程序集优先级很高一旦装进去bin 目录里那个 DLL 就变成摆设版本升级时如果忘了更新 GAC排错体验相当酸爽。注册命令很简单gacutil /i MySql.Data.dll gacutil /l MySql.Data sn -T MySql.Data.dllgacutil /i 执行安装需要管理员权限gacutil /l 列出当前 GAC 里所有 MySql.Data 版本用来确认安装结果sn -T 查看程序集的公钥令牌。8.0.13 官方构建是强名称签名的sn -T 输出应该包含 c5687fc88969c44d。如果 sn 报程序集未签名说明这个 DLL 不是官方构建不能进 GAC强行安装会失败。我个人对 GAC 的态度是能用 bin 部署就别碰 GAC。GAC 是个全局黑匣子多个版本共存时程序集绑定日志能把你绕晕。只有机器上确实有多个 .NET 应用需要共享同一版本时才值得走这条路。3.3 bin 目录部署与绑定重定向大多数项目其实不需要 GAC把 MySql.Data.dll 跟 exe 放在同一个目录就行。这是最简单的部署方式也最容易排查——文件摆在那儿版本对不对一眼能看出来。但现实是项目里可能还残留着老版本的引用比如某个公共类库带进来 6.9.x。这时程序集版本对不上就会抛绑定失败。在 app.config 或 web.config 里加一段绑定重定向把旧版本全部指到 8.0.13.0?xml version1.0 encodingutf-8? configuration startup supportedRuntime versionv4.0 sku.NETFramework,Versionv4.5.2 / /startup runtime assemblyBinding xmlnsurn:schemas-microsoft-com:asm.v1 dependentAssembly assemblyIdentity nameMySql.Data publicKeyTokenc5687fc88969c44d cultureneutral / bindingRedirect oldVersion0.0.0.0-8.0.13.0 newVersion8.0.13.0 / /dependentAssembly /assemblyBinding /runtime /configurationbindingRedirect 的意思是把所有 0.0.0.0 到 8.0.13.0 之间的引用请求统一重定向到 8.0.13.0。assemblyIdentity 里的 publicKeyToken 必须跟文件一致否则重定向不生效。如果你不想把所有依赖 DLL 都堆在 exe 目录可以在配置里加 probing 路径让 CLR 去子目录找runtime assemblyBinding xmlnsurn:schemas-microsoft-com:asm.v1 probing privatePathlibs;plugins / /assemblyBinding /runtimeprivatePath 是相对 exe 目录的子目录名多个目录用分号分隔。这个方案适合想保持根目录干净的项目但注意 probing 只管托管程序集管不了原生 DLL。4. C# 侧完整用法连接、参数化与事务的三段式模板4.1 连接串参数与连接池DLL 部署到位后写代码就顺了。连接串是第一个要抠的参数。先给一个生产环境常见的配置var connStr Server192.168.1.10;Port3306;Databaseerp; Uidapp_user;Pwd******;SslModePreferred; CharSetutf8mb4;ConnectionTimeout15; Poolingtrue;Min Pool Size2;Max Pool Size50;; using (var conn new MySqlConnection(connStr)) { conn.Open(); // 业务代码 }每个参数的取舍都有原因。Server 和 Port 不用多说3306 是 MySQL 默认端口。SslMode 在 8.0.13 里默认是 Preferred意思是能协商 TLS 就加密协商不了就退回明文如果服务器开启了强制 SSLPreferred 会自动切到加密连接不需要额外配置。CharSet 建议写 utf8mb4尤其是有 emoji 或生僻字的场景用默认 latin1 或 utf8 会在入库时变问号。参数默认值说明SslModePreferredNone / Preferred / Required 三档CharSetutf8mb4老连接器默认是 utf8注意区分ConnectionTimeout15建连超时秒数不是命令超时Poolingtrue连接池开关建议保持开启Min Pool Size / Max Pool Size0 / 100按并发量调别设太大连接池这块有个常见误解Min Pool Size 不是预创建连接数而是池子低于这个数时会补齐。设成 2 是为了避免早上第一波请求全部打到建连上代价是程序启动时会多两个空闲连接占着。4.2 参数化查询与 MySqlParameter 类型SQL 拼接字符串是最容易翻车的写法注入是另一回事光是日期格式和单引号转义就够头疼。用参数化查询是必须的习惯。简单示例using (var conn new MySqlConnection(connStr)) using (var cmd new MySqlCommand( SELECT * FROM t_order WHERE order_no orderNo AND status status, conn)) { cmd.Parameters.AddWithValue(orderNo, orderNo); cmd.Parameters.AddWithValue(status, status); conn.Open(); using (var reader cmd.ExecuteReader()) { while (reader.Read()) { // 映射实体 } } }AddWithValue 很方便但类型推断有陷阱。status 如果是 int它按 Int32 传如果是 null它按空值传MySQL 端可能因为类型不匹配走不了索引。日期、decimal、布尔值这些类型我一般会显式声明 MySqlDbType让数据访问层的行为稳定可预期cmd.Parameters.Add(new MySqlParameter(status, MySqlDbType.Byte) { Value status }); cmd.Parameters.Add(new MySqlParameter(amount, MySqlDbType.Decimal) { Value amount, Precision 10, Scale 2 }); cmd.Parameters.Add(new MySqlParameter(createTime, MySqlDbType.DateTime) { Value DateTime.Now });显式声明之后MySQL 端收到的是精确类型不会因为 C# 侧的隐式转换产生歧义。Precision 和 Scale 对应 decimal(10,2)这里写的是参数本身的精度跟表结构里的精度可以不一致但一致更省心。4.3 事务、批量插入与 MySqlBulkLoader涉及多行写入时逐条 INSERT 的性能在数据量大时会很难看。两个方向一个是用事务包住批量参数化插入一个是直接上 MySqlBulkLoader。先看批量参数化。这里的关键是复用同一个 MySqlCommand循环里只改参数值using (var conn new MySqlConnection(connStr)) { conn.Open(); using (var tx conn.BeginTransaction()) using (var cmd new MySqlCommand()) { cmd.Connection conn; cmd.Transaction tx; cmd.CommandText INSERT INTO t_order_detail (order_no, sku, qty, price) VALUES (orderNo, sku, qty, price); cmd.Parameters.Add(new MySqlParameter(orderNo, MySqlDbType.VarChar, 32)); cmd.Parameters.Add(new MySqlParameter(sku, MySqlDbType.VarChar, 32)); cmd.Parameters.Add(new MySqlParameter(qty, MySqlDbType.Int32)); cmd.Parameters.Add(new MySqlParameter(price, MySqlDbType.Decimal)); foreach (var item in items) { cmd.Parameters[0].Value item.OrderNo; cmd.Parameters[1].Value item.Sku; cmd.Parameters[2].Value item.Qty; cmd.Parameters[3].Value item.Price; cmd.ExecuteNonQuery(); } tx.Commit(); } }先 Add 参数再循环里赋 Value避免每次迭代重建参数集合这一招在小数据量下看不出差别上万行时差距很明显。事务包住是必须的否则中途出错会留下半截数据回滚都没法回。如果是十万级以上的数据迁移参数化批量插入也不够看改用 MySqlBulkLoader 直接灌 CSVvar loader new MySqlBulkLoader(conn); loader.TableName t_order_detail; loader.FieldTerminator ,; loader.LineTerminator \r\n; loader.FileName orders.csv; loader.Local true; int affected loader.Load();MySqlBulkLoader 对应的是 LOAD DATA LOCAL INFILE走文件导入比逐条 INSERT 快一个数量级。Localtrue 表示文件在客户端如果不开 local_infileMySQL 8.0 默认会拒绝这种导入方式。用之前先跟 DBA 确认服务器开了 local_infile没开的话这条路径走不通。提示MySqlBulkLoader 的字段顺序默认按表结构顺序映射CSV 列和表列不一致时先建临时表再导别硬着头皮对列。5. 避坑排查DLL 加载失败的五个现场与对策5.1 BadImageFormatException平台目标不一致现象程序启动后第一行就抛 System.BadImageFormatException异常信息里指向 MySql.Data.dll或者指向某个 COM 组件。原因进程以 64 位运行但加载链里有 32 位模块。最常见的组合是主体项目 AnyCPU 引用了 32 位 COM 组件或者主体项目显式 x64 引用了 x86 的 MySql.Data.dll。位数混搭在编译期检查不出来只有运行时 CLR 真正去加载模块才会暴露。解决统一平台目标。主体项目、依赖项目、MySql.Data.dll 三者必须同一个位数。在 csproj 里把 PlatformTarget 全部设为 x86前提是你确实需要 32 位或者全部切到 x64 并换用 x64 版 MySql.Data.dll。二选一没有中间态。5.2 程序集版本冲突8.0.13.0 与旧版本正面撞车现象程序能启动但执行到某个数据库调用时报 Could not load file or assembly MySql.Data, Version8.0.13.0, Cultureneutral, PublicKeyTokenc5687fc88969c44d有时异常里还会带出 6.9.10 之类的旧版本号。原因GAC 或 bin 目录里同时存在多个版本的 MySql.Data.dll。CLR 按请求版本找程序集时拿到的却是另一个版本又没配置 bindingRedirect 做映射。NuGet 升级后有时候会自动生成重定向但手动引用 DLL 时不会。解决先 gacutil /l MySql.Data 查 GAC确认机器上有哪些版本把旧的卸掉再清空 bin 目录重新编译排除复制了历史 DLL 的可能最后在 app.config 里补上 3.3 里的 bindingRedirect。改完之后用 fuslogvw 看一次绑定日志确认实际加载的路径和版本。5.3 原生依赖清单microsoft.vc80.mfc 与并行配置错误现象DLL 部署到某台新机器上启动时报应用程序无法启动并行配置不正确或者找不到 msvcp80.dll。事件日志的 SideBySide 条目里能看到一行 manifest 信息microsoft.vc80.mfc, processorarchitecturex86, typewin32, version8.0.50608.0。原因某个原生组件走 WinSxS 并行清单注册了对 VC 2005 运行库的依赖机器上没有对应版本的运行库。注意这不是 MySql.Data.dll 托管部分的依赖而是完整安装包里工具链或其它原生封装带来的。很多人对着托管 DLL 检查半天方向完全偏了。解决安装对应版本的 Visual C 2005 运行库vcredist_x86.exe或者在应用程序目录里放一份 msvcp80.dll 做本地部署。WinSxS 模式下优先装运行库本地 DLL 是最后手段会影响全局加载优先级。5.4 部署脚本被 PowerShell 执行策略拦下现象在构建机或新服务器上跑部署脚本执行到一半被拦错误信息形如无法加载文件 D:\Program Files (x86)\nodejs\npm.ps1因为在此系统上禁止运行脚本用 PowerShell 想加载 MySql.Data.dll 做版本校验也被同样拦截。原因Windows 默认 ExecutionPolicy 是 RestrictedPowerShell 脚本、.ps1 文件不被信任连带 [Reflection.Assembly]::LoadFrom 这种动态加载也被策略挡住。这跟 DLL 本身没关系但部署流程会卡在这一步让人误以为 DLL 有问题。解决只对当前会话放开策略不要动系统全局设置。Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned或者调用时直接跳过策略检查powershell -ExecutionPolicy Bypass -File deploy.ps1Bypass 只在这次调用生效不改注册表适合 CI/CD 构建机。生产服务器上建议保持 Restricted部署走其它方式别依赖 PowerShell 脚本。5.5 COM 场景的 32 位注册regasm 走错视图现象项目通过 COM 互操作调用 C# 写的数据库访问组件组件内部用了 MySql.Data.dll x86 版。注册完成后调用时返回 80040154类未注册或提示组件没有正确注册。原因regasm.exe 有 32 位和 64 位两个版本分别在注册表的不同视图里写 CLSID。x86 程序集必须用 32 位 regasm 注册用默认的 64 位 regasm 注册会写进 64 位视图32 位进程根本看不到。解决用 SysWOW64 下的 regasm 重新注册。C:\Windows\SysWOW64\regasm.exe MySql.Data.dll /codebase/codebase 参数告诉注册器从指定路径加载程序集适合没进 GAC 的场景。注册完成后用 32 位 PowerShell 或 32 位测试进程验证不要用 64 位工具测试 32 位组件结果没有参考意义。6. 用 corflags 与 dumpbin 做最后验证一分钟确认 DLL 位数与依赖6.1 三件套验证流程把 DLL 部署到 bin 目录之前我习惯先跑一遍三件套验证。CorFlags、dumpbin、fuslogvw 各管一摊配合起来能把加载问题提前拦在门外。先看平台标记。在 Visual Studio 开发人员命令提示符里执行corflags MySql.Data.dll输出里重点看这几行Version : v4.0.30319 PE : PE32 ILONLY : 1 32BITREQ : 1 32BITPREF : 0PE 是 PE32 表示 32 位 PE 格式不是 PE32PE32 才是 64 位。32BITREQ 为 1 表示这个程序集强制要求 32 位进程32BITPREF 为 0 说明它不是偏好 32 位的 AnyCPU而是硬性 x86。这两个标志组合是判断文件类型最可靠的依据。然后看原生依赖dumpbin /dependents MySql.Data.dll输出会列出所有原生 DLL 依赖。对于纯托管的 MySql.Data.dll这里应该很干净最多是系统标准库。如果看到 msvcp80.dll、mfc80.dll 这类第三方运行时就要留意目标机器上有没有对应运行库——这正是 5.3 里那个坑的前置检查。最后是绑定失败日志。fuslogvw 是 Assembly Binding Log Viewer管理员身份打开后先开启日志然后运行你的程序触发一次 DLL 加载再到 fuslogvw 里刷新。日志里会写明 CLR 去哪里找了程序集、找到的是哪个版本、为什么拒绝。这一手在版本冲突排查里比看异常栈直观得多。提示fuslogvw 默认只记录失败的绑定要记录成功绑定得在设置里打开All选项。生产机器上别常开日志文件膨胀很快。这三板斧走完DLL 的位数、依赖、运行时绑定行为全部透明。以前我拿到来路不明的 MySql.Data.dll直接往 bin 目录一丢就跑被版本冲突坑了一整个下午之后现在每次都会先跑 corflags 和 dumpbin确认平台标记和依赖清单再谈部署。这套流程顺手到几乎不占额外时间但能把六成以上的加载问题提前掐掉。这份 8.0.13 x86 的程序集你拿到手也用同样方式过一遍加载问题会少掉大半。希望帮到你。本文还有配套的精品资源点击获取