简介面向.NET开发者的MySQL连接组件合集集中收录mysql.data.dll多个版本及配套文件用于解决不同.NET Framework与MySQL服务器版本之间的兼容匹配问题。整个RAR压缩包共210个文件大小约18.49MB其中138个dll覆盖常用官方驱动版本并包含MySql.Parser.dll等解析器组件便于在项目间替换和对比59个txt文件保留版本说明与变更日志chm帮助文档、readme和license则提供接口用法、授权范围等关键信息。对维护旧系统、迁移环境或排查连接失败的开发者而言这套资源相当于本地备用的“版本仓库”省去逐个官网寻找和比对不同dll的时间也降低了因版本不匹配导致运行异常的风险。压缩包内文件用途划分清晰驱动库、解析器、文档与许可文本一目了然方便快速定位所需版本。目前已有3775人浏览/学习适合中高级.NET工程师在开发调试时按需取用。1. 别再为“mysql.data.dll 各版本下载 最全”熬夜了你缺的不是文件是版本坐标系做 .NET 的人几乎都经历过这种深夜新拉下来的项目编译不过报错指向“无法加载 Mysql.Data”于是开始全网搜“mysql.data.dll 各版本下载 最全”从某个镜像站拖下来一个 dll扔进 bin 目录报错变成“未能加载文件或程序集”再换一个版本又变成“方法未找到”。折腾到凌晨一点发现机器上装了好几个版本的 Mysql.Data连哪个是项目真正需要的都分不清。这个标题真正要解决的不是“哪里能下载到所有版本”而是“我的项目到底该用哪个版本以及怎么让运行时精确加载它”。这篇笔记就沿着这条线把 Connector/NET 的版本体系、选型规则、获取与验证路径讲清楚新手能照着把环境搭起来熟手能直接拿去排查部署事故。2. 认识 Mysql.Data.dll 的版本坐标系Connector/NET 与 .NET 框架的绑定关系2.1 版本号拆解程序集版本、文件版本与 Connector/NET 发行版如何对齐Mysql.Data.dll 不是孤立存在的文件它是官方 MySQL Connector/NET 组件.NET 平台下的官方驱动的核心程序集。所以“各版本下载”的本质是去下载不同发行版的 Connector/NET再从中取出对应目标框架的 Mysql.Data.dll。你会在文件属性里看到三个版本号它们经常不一样这是第一个让人翻车的地方。程序集版本Assembly Version是运行时用于匹配的版本写在强名称里CLR 加载时拿它跟引用方的版本号做对照。文件版本File Version是构建产物自己的版本Windows 资源管理器里显示的多半是它。而 Connector/NET 发行版版本是一套独立的产品线版本号。这三者最典型的关系是Connector/NET 8.0.x 的程序集版本是 8.0.x文件版本可能是 8.0.x.xxxxx后面多出构建号。而 Connector/NET 6.9.x 的程序集版本是 6.9.12文件版本同样带一个长尾巴。因为程序集版本通常只取产品主版本号所以同一大版本内的小版本升级不会改变程序集版本这也是很多“我明明换了新 dll 为什么还报旧版本”疑问的来源。判断一个 Mysql.Data.dll 是哪个发行版别只看文件名和文件大小正确姿势是右键属性切到“详细信息”看文件版本或者直接用命令行sn -T查看程序集的公钥令牌和元数据。我见过某同事把 8.0.x 的 dll 改名为 6.9.x 放进去骗过编译期检查结果运行时直接抛强名称验证失败——版本不是靠文件名维护的是靠程序集清单维护的。下面这段代码可以快速读出一个 Mysql.Data.dll 的程序集版本和公钥令牌适合拿到不明来源 dll 时的第一道体检需要 .NET SDK 环境在项目目录下建一个控制台项目直接跑。using System; using System.Reflection; class Program { static void Main(string[] args) { // 传入 dll 的绝对路径例如 D:\libs\Mysql.Data.dll string path args.Length 0 ? args[0] : D:\libs\Mysql.Data.dll; Assembly asm Assembly.LoadFrom(path); AssemblyName name asm.GetName(); Console.WriteLine(FullName: name.FullName); Console.WriteLine(Version : name.Version); Console.WriteLine(Culture : (name.CultureInfo ?? CultureInfo.InvariantCulture).Name); } }这段代码用Assembly.LoadFrom按路径加载程序集并读取清单信息不依赖项目里已有的引用所以适合拿来做“脏文件体检”。FullName会输出类似Mysql.Data, Version8.0.33.0, Cultureneutral, PublicKeyTokenc5687fc88969c44d的内容这里面 Version 和 PublicKeyToken 就是后面写绑定重定向要用的关键值。需要注意LoadFrom在程序集已被其他上下文加载时可能返回缓存实例对“只看版本”这个用途没有影响。2.2 按运行时选型.NET Framework 与 .NET Core/5 两套分支怎么挑选版本的第一原则不是“越新越好”而是“你的运行时支持什么”。Connector/NET 从版本号上大致分成两代6.x/8.0 之前的老体系以及 8.0 开始的新体系。8.0 之后官方把对 .NET Framework 的支持收窄到 4.5.2 及以上同时对 .NET Core / .NET 5 做了正式支持对应的 lib 目录下开始出现 netstandard2.0、net6.0 等子目录。如果你的项目是 .NET Framework 4.5 以下的老系统新版本 dll 在编译期就会提示不兼容反过来.NET Core 3.1 以上项目用 6.9.x 也会在运行时出现平台支持错误因为老驱动默认按 .NET Framework 的 API 面编译。我一般按这张表选型这也是处理了大量遗留项目后的血泪总结。判断依据就三条目标框架、MySQL 服务端版本、是否需要 EF Core 集成。纯 ADO.NET / MySqlConnection 场景选型最简单涉及 EF Core 时EF Core 本身还要求驱动版本和 Oracle 提供的另一个包配套选型维度多一层建议在测试环境先跑一遍基础 CRUD 再定版。Connector/NET 发行版目标框架MySQL 服务端兼容适用项目形态6.9.12.NET Framework 2.0/4.0/4.5MySQL 5.5/5.6/5.7老 WebForms、WinForms 遗留系统6.10.x.NET Framework 4.5.2MySQL 5.6/5.7/8.0 备选需要连接字符串特性修补的老项目8.0.x.NET Framework 4.5.2 / net6.0 / netstandard2.1MySQL 5.7 / 8.0新项目首选含 LTS 分支8.4.xnet6.0 / net8.0MySQL 8.0 / 8.4新项目且能用创新分支9.xnet6.0 / net8.0MySQL 8.x / 9.x需要新特性且接受创新分支选型时还有个常见误用值得提醒只看 NuGet 包名。NuGet 上叫MySql.Data的包对应官方驱动而叫MySqlConnector的是第三方开源驱动两者程序集名都含 Mysql.Data 相关字样但强名称公钥令牌不同混用会引发“找到 Mysql.Data 但版本不匹配”。已踩过坑的开发者大多有过这种经历项目里同时安装了 MySql.Data 8.0.x 和另一个依赖自带的 MySql.Data 6.9.x运行时按版本号就近加载导致行为不一致排查了半天才发现是同时引了两套驱动。版本选型还有个隐藏的判断点就是连接串参数。早期版本支持的Allow User Variables、Treat Tiny As Boolean这些参数在新版本里被重命名或移除直接把旧配置搬到新驱动上经常出现“配置项不识别”的异常。所以换驱动版本时不要只换 dll把连接串也对照当前版本的官方参数列表过一遍这一步能省掉后面一整晚的排错。3. 拿到正确的 Mysql.Data.dll三条获取途径与下载核对步骤3.1 途径一官方 NuGet 包解出 dll 并核对目标框架最常见的做法是从 NuGet 拉包。NuGet 包里 Mysql.Data 的目录结构是分层的lib/下按目标框架拆成net45、net48、net6.0、netstandard2.1等子目录每个目录里有一个对应框架编译好的 Mysql.Data.dll。很多人把包里所有 dll 一起拷进 bin这是多余的还会引入错误的程序集版本。正确做法是只取匹配项目的那个子目录。命令行拉包的方式比较可控适合在 CI 或批处理脚本里固定版本。# 指定版本拉包到当前目录下的 packages 文件夹-OutputDir 是输出位置 nuget install MySql.Data -Version 8.0.33 -OutputDir packages -Source https://api.nuget.org/v3/index.json # 查看包内文件清单确认目标框架目录 unzip -l packages/MySql.Data.8.0.33/lib/net6.0/MySql.Data.dll第一条命令会创建一个packages/MySql.Data.8.0.33目录里面除了lib还有_rels、package这类元数据文件。之前提过不要拿整个目录往项目里扔理论上只要lib下对应目标框架那个 dll。-Source参数显式指定源地址避免本机配置了私有源时拉错包这条经验来自某次用公司私有镜像源拉到旧缓存包的翻车现场源地址里的域名被替换成私有仓库后版本号还是那个版本号dll 却是旧的。如果你在离线环境先在有网机器上拉包再拷贝.nupkg然后用nuget install的本地源模式解包。3.2 途径二安装器里的程序集缓存目录另一条常见路径是 MySQL 官方安装器安装 Connector/NET 组件后本机文件系统里会出现一份程序集。多数情况下安装器会把 Mysql.Data.dll 注册进 GAC同时会在安装目录下保留一份副本。问题是 GAC 里的版本被系统隐藏很多人以为没装成功于是又去别处下载结果机器上出现了多个版本。我一般这样做先查 GAC 里已有的版本再决定是否需要手动放文件。# 查 GAC 中 MySQL 相关程序集Windows 系统下用 gacutil gacutil /l | findstr /i Mysql.Data # 查安装器默认目录是否存在驱动副本 dir C:\Program Files (x86)\MySQL\MySQL Connector NET 8.0.x\Assemblies /sGAC 里的版本号输出结果会包含完整程序集名例如Mysql.Data, Version8.0.33.0, Cultureneutral, PublicKeyTokenc5687fc88969c44d。如果你的项目引用版本和 GAC 版本一致运行时不一定要把 dll 复制到 bin但发布到没有安装驱动的服务器时仍然必须带一份到 bin 目录。第二条命令的路径在不同机器上有差异找不到时就以gacutil /l的输出为准那个是程序集实际登记的位置可靠程度高于安装目录的路径猜测。3.3 途径三从已部署项目反查版本并用独立工具校验最容易被忽略的获取方式是从“已经在正常跑的旧项目”里拷贝。这类 dll 经历过多环境验证版本与业务代码是匹配的。但拷贝之前必须做一次版本检查确认它就是 bin 目录里实际加载的那份而不是某些工具回滚残留的旧文件。检查时用 PowerShell 读取文件版本和程序集版本这是只读操作不需要额外安装工具。# 读取文件的程序集版本与文件版本路径按实际修改 $path D:\old_project\bin\Mysql.Data.dll $asm [System.Reflection.AssemblyName]::GetAssemblyName($path) Write-Host AssemblyVersion: $($asm.Version) Write-Host FileVersion: $((Get-Item $path).VersionInfo.FileVersion)AssemblyName.GetAssemblyName是静态方法只读程序集清单不会加载其中的代码所以即使 dll 依赖的其他库缺失也不影响这个命令。当你从运行中的项目复制 dll 时最好同时把项目里对应的连接串配置也带回来因为连接串参数和驱动版本是配套的单拿 dll 回去接到旧连接串上可能因为参数不识别直接抛异常。这里要刻意提醒一句不要从搜索引擎找到的“某某 dll 下载站”拿文件。这类站点上的 dll 版本标注经常是错的而且压缩包名称和文件内部版本号不一致是常态。某个被反复转存的 6.9.12 包实际文件版本是 8.0.22装上后连接 MySQL 8.0 服务端报错看不出来源。正确顺序永远是先确认运行时再取官方源或已验证的本地副本最后做版本核对。4. 把 dll 装进项目并保证运行时加载正确bin 目录、绑定重定向与发布检查4.1 Visual Studio 里引用与 Copy Local 的正确姿势拿到正确版本的 dll 只是第一步项目里怎么引用它决定了运行时能否按预期加载。在 Visual Studio 里添加引用有两种操作分别是“添加程序集引用”和“添加项目引用”如果是拿来主义右键引用 → 添加引用 → 浏览然后选中下载好的 Mysql.Data.dll 即可。添加后必须检查属性面板里的Copy Local这是引用被复制到输出目录的开关默认情况下 dll 引用为 True但从 GAC 添加引用时 Visual Studio 会把它置为 False。Copy Local 为 False 意味着编译后 bin 目录里没有这个 dll运行时会去 GAC 找。开发机上因为装过安装器GAC 里有匹配版本程序跑得好好的发布到干净服务器后bin 里没有 dll直接报找不到程序集。排查这种问题的最佳方式不是反复改配置文件而是在项目文件里直接看引用项的 XML 描述。ItemGroup !-- 项目文件里引用项的典型形态CopyLocal 由 Private 控制 -- Reference IncludeMysql.Data HintPath..\packages\MySql.Data.8.0.33\lib\net6.0\Mysql.Data.dll/HintPath Privatetrue/Private /Reference /ItemGroupPrivate标签对应属性面板的Copy Localtrue表示复制到输出目录。如果这里是false可以把Private删掉或改为true后重新生成。HintPath写的是 dll 的相对路径这个路径在项目文件移动后会失效编译报错时先看这个路径是否还指向真实文件。4.2 web.config / app.config 绑定重定向怎么写绑定时通过配置文件把引用版本映射到实际版本。最常见的部署事故是项目里多个程序集引用不同版本的 Mysql.DataCLR 在加载时不知道听谁的于是用就近原则先加载先遇到的结果某个调用方需要的方法在新版本里签名变了直接抛 MissingMethodException。写绑定重定向就是在配置文件中声明“凡是引用 6.9.x 到 8.0.x 的统一加载 8.0.33”。configuration runtime assemblyBinding xmlnsurn:schemas-microsoft-com:asm.v1 dependentAssembly assemblyIdentity nameMysql.Data publicKeyTokenc5687fc88969c44d cultureneutral / bindingRedirect oldVersion0.0.0.0-8.0.33.0 newVersion8.0.33.0 / /dependentAssembly /assemblyBinding /runtime /configuration这个配置块里assemblyIdentity的name和publicKeyToken必须与程序集清单完全一致公共语言运行时CLR以此作为匹配键。oldVersion区间写宽了覆盖范围广但也会掩盖版本冲突我习惯把oldVersion下限写成0.0.0.0以覆盖预编译阶段的默认引用版本。publicKeyToken的值不要凭记忆填用前面sn -T或 PowerShell 命令输出的结果填错会导致绑定完全失效运行时回到原始版本号加载。很多人在配置文件里重复写多个dependentAssembly块以为可以同时映射多个版本其实同一程序集只认最后一个匹配项。而且程序集绑定只看程序集名和 token不看文件路径所以把新旧 dll 同时放进 bin 目录是无效的最终加载哪个由重定向决定物理文件保留旧版只会增加迷惑性。4.3 发布目录的自检清单发布前我习惯按清单核对一遍目录能避免绝大多数“本机好、线上崩”的问题。第一查 bin 里 Mysql.Data.dll 的版本是否与引用版本一致。别只看文件大小用Get-AuthenticodeSignature或文件版本信息确认验证的 PowerShell 命令在前面已经写过。第二查配置文件的绑定重定向是否随发布一起出去了。Web 项目发布后会在输出目录生成 web.config但有时候它会合并到发布配置里与本机调试用的配置不同导致重定向丢失。第三查是否有多余的旧版本 dll 残留在子目录。有些发布工具会把整个 packages 目录拷进去bin 下层出现packages\MySql.Data.6.9.12\lib\net45\Mysql.Data.dll不影响主 bin 的加载但会造成后续维护者误判。这套自检不依赖任何第三方工具发布脚本里加三个判断即可。我一般在 CI 的发布步骤里写一个 PowerShell 检查脚本判断 bin 目录里 Mysql.Data.dll 的程序集版本是否满足预期的版本区间不满足直接让流水线失败。这一步把“人为记忆版本”变成“构建自动校验”从机制上消除了最常犯的低级错误。5. 版本混用排查五条高频踩坑记录与处置方法5.1 运行时抛出找不到 Mysql.Data 的异常现象明明安装了 dll项目也能编译但运行时抛System.IO.FileNotFoundException: 无法加载文件或程序集“Mysql.Data, Version8.0.33.0”。原因异常信息里的版本号是引用方期望的版本不是 bin 里实际存在的版本。常见情况是代码里手动引用了 8.0.33但 bin 目录里还躺着 6.9.12CLR 按程序集名找找到了文件但比对强名称版本时发现不匹配最终以找不到收场。另一个原因是配置文件里的绑定重定向写错 publicKeyToken导致 CLR 不认这个重定向按原始版本号找找不到就报错。解决先看异常里的版本号再确认 bin 里文件的程序集版本最后核对配置文件。快速确认加载失败点的办法是开启程序集绑定日志把 .NET 的 Fusion Log 打开它会记录 CLR 搜索 dll 的完整路径列表错误原因一目了然。不过日志打开后比较占磁盘排查完要记得关掉。5.2 本机能跑线上崩GAC 与 bin 目录的加载顺序差异现象开发机上程序秒开发布到服务器一运行就报错且错误信息里出现了开发机上没有见过的程序集版本。原因开发机上 GAC 里有驱动运行时优先从 GAC 取服务器上没有装驱动程序只能从 bin 目录取但 bin 里没有对应版本。更隐蔽的版本是开发机 GAC 里有 6.9.12项目引用 8.0.33Copy Local 为 False本地运行时 CLR 因 GAC 加载顺序靠前而采用了 6.9.12业务代码在本地一直跑的是旧版本发布后到了干净环境才暴露。解决统一以 bin 目录为准。检查每个引用 Mysql.Data 的项目的Copy Local是否为 True发布前把开发机 GAC 里的版本与 bin 目录版本强制对齐。另一个偏方是把 GAC 拉到前面加载的行为看成一票否决项即不要依赖 GAC所有环境一律用 bin 目录文件。这样虽然本机能跑不代表线上能跑但反过来本机跑不了的一定线上跑不了问题域缩小了一半。5.3 老版本连不上 MySQL 8.0 服务端握手阶段就失败现象连接字符串完全正确端口、账号都对但Open()抛Authentication to host x.x.x.x for user root using method caching_sha2_password failed或者直接是 SSL 协商错误。原因MySQL 8.0 默认认证插件是caching_sha2_password6.9.x 及更老版本驱动不认识这个插件握手时协议不一致。另一层原因是 TLS 版本服务端默认要求安全连接老驱动支持的 TLS 协议版本偏低被服务端拒绝。两者都会在连接建立阶段失败报错具体位置不同但根子都在驱动太旧。解决优先升级驱动到 8.0.x新驱动完整支持caching_sha2_password。如果项目绑死老框架无法升级可以把服务端用户的认证插件降为mysql_native_password但这是改服务端配置多环境协同时要评估影响。紧急情况下连接串里加SslModeNone可以绕过 TLS 协商但明文传输在生产环境不是好选择只建议在内网测试环境临时用。5.4 中文乱码与字符集错乱现象查询出来的中文是问号或乱码写入的数据再读出来对不上但数据库表结构确认是 utf8mb4。原因连接串里没有指定CharSet驱动按默认字符集与服务器通信。老版本驱动的默认字符集可能不是 utf8mb4多字节字符在传输转码中被截断。另一个原因是驱动版本和服务器版本对utf8mb4的支持不对齐有些版本虽然写了 CharSetutf8mb4但底层映射表不完整。解决连接串显式加CharSetutf8mb4;同时确认 dll 版本支持该字符集。如果加了还是乱码下一步检查数据库连接的服务器端字符集变量SHOW VARIABLES LIKE character_set_server以及表字段的真实字符集。排查思路按“连接串 → 驱动版本 → 服务端变量”的顺序查不要把顺序反过来否则容易在表结构上浪费大量时间。5.5 批量操作时报 packets out of order 或连接频繁断开现象单条增删改查正常一跑批量任务就抛Packets out of order或连接假死偶发重连成功但程序状态已经混乱。原因这种报错在老版本驱动批量执行存储过程或大事务时出现概率高与连接串里的Connection LifeTime、Max Pool Size参数配置有关。更常见的根子是服务端max_allowed_packet小于批量语句包体的大小连接被服务端强制断开。驱动版本越旧对包体的拆分处理越粗糙触发概率越高。解决先查服务端max_allowed_packet配置并适当调大再在连接串里显式设置Poolingtrue;Max Pool Size100;Connection LifeTime300;。这里的关键是Connection LifeTime别设太小太小会导致连接频繁重建重建过程又叠加批量语句的执行时间最终表现为“连接池爆炸”。如果升级驱动后问题仍在不要继续调参数抓网络包看服务端断开时的返回码定位到具体语句再优化。6. 验证 Mysql.Data.dll 是否真的“装对了”最小探测程序与三层检查6.1 最小连接探测代码最后提供一套可以反复使用的验证方法用来快速确认“当前加载的 dll 版本 连接串参数 服务端版本”三者匹配。这段代码直接放进控制台项目替换连接串即可。using System; using MySql.Data.MySqlClient; class Program { static void Main() { // 连接串里的参数决定了驱动走哪条协议路径 string connStr Server127.0.0.1;Port3306;Databasetest;Uidroot;Pwdyourpass;CharSetutf8mb4;SslModePreferred;Connection Timeout5;; using (var conn new MySqlConnection(connStr)) { try { conn.Open(); // ServerVersion 由服务器返回能确认服务端实际版本 Console.WriteLine(ServerVersion: conn.ServerVersion); // 连接 ID 确认服务器接受了新连接 Console.WriteLine(ConnectionId : conn.ConnectionId); using (var cmd conn.CreateCommand()) { cmd.CommandText SELECT VERSION(), character_set_server; using (var reader cmd.ExecuteReader()) { while (reader.Read()) { Console.WriteLine(MySQL Version: reader.GetString(0)); Console.WriteLine(Server Charset: reader.GetString(1)); } } } } catch (Exception ex) { // 握手失败、认证失败、字符集错误都在这里暴露 Console.WriteLine(Error: ex.Message); } } } }这段程序承担两个功能一是确认 dll 能和服务端建立完整连接二是把服务端的真实版本和字符集打印出来便于跟驱动选型对照。Connection Timeout5保证连接失败时快速返回而不是无限等待排查动作不至于卡死。SslModePreferred表示优先建立 SSL 但不强制如果老驱动不识别这个参数说明 dll 版本太旧正好暴露问题。执行后若打印出 ServerVersion 和字符集那么驱动、连接串、服务端三者的匹配已经通过基础验证。6.2 三层验证与一套收尾习惯在这个基础上形成三层验证习惯第一层用上面这段程序验证连接本身第二层在项目代码里打印typeof(MySqlConnection).Assembly.GetName().Version确认运行时实际加载的是预期版本这一步能发现配置文件重定向是否生效第三层在发布服务器上重复第一层验证保证部署环境与开发环境行为一致。三层验证都通过后再用最简单的 CRUD 往表里写入中文和特殊字符数据并读回比对确认字符集链路完整。我把这个步骤固定为一个清理习惯每次升级驱动后先跑探测代码再跑数据回读最后清空测试数据收尾。希望这套方法能帮你在下次遇到 Mysql.Data 版本问题时把整晚的通宵排查压缩成半小时内的验证动作。本文还有配套的精品资源点击获取