MySQL驱动安装与排障：ODBC/JDBC、32/64位与认证协议全解析

很多新手第一次接触“MySQL 驱动程序”这个词，通常是在某个软件突然弹出一句“无法加载驱动程序”或者“找不到合适的驱动”的时候。我接过不少这样的求助：MySQL 服务端明明装好了，命令行里也能登录，但 Navicat 连不上、Java 项目报 ClassNotFoundException、Access 里想导入 MySQL 数据却弹一串驱动错误。这些问题的共同点，是大家把“MySQL 驱动程序”理解成了“一个装了就能用的东西”，而没有意识到它其实是一个需要跟程序语言、系统位数、服务端认证方式全都对得上的独立组件。这篇就顺着连接链路讲清楚：驱动到底是什么、什么时候需要手动装、怎么装、装完连不上怎么查。

1. 先弄清“MySQL 驱动程序”到底在驱动什么

1.1 驱动是协议翻译官，不是“装一个软件”

MySQL 服务端本身是一个网络服务，它监听 3306 端口，等待客户端用 MySQL 协议来跟它对话。而 MySQL 协议是一套二进制的通信规范，不是随便哪个软件天生就会说的。应用程序（Java、Python、C#、Access、Navicat）并不知道怎么把这个协议凑出来，它们需要借助一个组件，把“我要查数据”“我要写数据”这样的业务意图翻译成协议报文，再把服务端返回的结果翻译回程序能用的数据结构——这个组件就是驱动。

所以驱动本质上是个协议翻译官。你的程序负责业务逻辑，驱动负责把逻辑里的数据库操作翻译成 MySQL 能理解的网络请求。如果你缺了驱动，程序连 MySQL 的大门都摸不到；如果你装错了驱动，明明大门就在面前，你也进不去。

明白这一点之后，很多困惑就能解开。比如为什么 MySQL 驱动有那么多版本和形态？因为每个语言、每个工具都有自己的一套调用方式，驱动必须能嵌进那个环境里才能发挥作用。Java 的 JDBC 驱动是一个 jar 包，Python 的驱动是一个 pip 安装模块，Windows 应用的 ODBC 驱动则是一个安装程序。它们外观完全不同，底层做的事情却是一模一样的。

1.2 常见的驱动家族：ODBC、JDBC、原生连接器、GUI 内置

我整理了一个常见的驱动类型表，方便你对号入座：

这里要专门说一句：GUI 工具通常已经打包好了驱动，所以很多人装了 Navicat 就能连，根本不需要手动折腾。如果你在 Java、Access、BI 工具里连 MySQL，才需要按场景主动选驱动。这也是“为什么教程都让我装驱动，我却没装过”的核心原因——不是驱动不重要，而是你的工具早就帮你装好了。

1.3 什么情况下需要手动安装驱动

需要手动安装 MySQL 驱动，通常就这几类：

• 程序报错 “No suitable driver found” 或 “ClassNotFoundException: com.mysql.cj.jdbc.Driver”
• 用 Access/Excel 通过 ODBC 访问 MySQL 数据
• 某些 BI 工具、自动化软件、老旧的报表系统通过 ODBC 连接数据库
• 开发框架（比如 Delphi 的 FireDAC）底层依赖 libmysql.dll

如果用命令行 mysql 客户端连接，不需要单独装驱动，因为 mysql 客户端自己已经实现了协议。这一点经常被混淆，其实命令行本质上就是一个自带驱动的客户端程序，只是它长得比较朴素，让大家忽略了它也有“驱动”这件事。

2. Windows 下安装 ODBC 驱动的完整流程与 32/64 位抉择

2.1 下载前先想清楚的：位数、版本、Unicode/ANSI

如果你确定要走 ODBC 这条路，下载驱动之前先把三件事想清楚，否则很容易白装一遍。

第一是版本。MySQL 官方提供的 Connector/ODBC 目前主要是 8.0.x，老一点的还有 5.3.x。新环境建议直接用 8.0.x，因为老驱动不认识 MySQL 8.0 的默认认证插件；但如果你服务端是 MySQL 5.6/5.7，8.0 驱动也能兼容向下连接。反过来，如果服务端已经是 8.0，还守着老 ODBC 驱动不放，就会碰上后面要讲的认证协议报错。

第二是位数。这一点最容易出错。决定装 32 位还是 64 位驱动的，不是 Windows 系统本身，而是调用驱动的那个程序的位数。举个例子：Windows 11 是 64 位系统，但你装的 Office 很可能是 32 位版本，那么 Access 就是 32 位进程，它只能加载 32 位 ODBC 驱动。这时候哪怕你装了正确的 64 位 MySQL ODBC，Access 照样找不到驱动。反过来，64 位程序也用不了 32 位驱动。简单记：驱动位数 = 客户端程序位数，不是系统位数。

第三是 Unicode/ANSI。新环境一律选 Unicode Driver。ANSI 驱动在中文环境下容易出现字符集转换问题，旧系统里为了兼容才用，新项目没必要给自己挖坑。

2.2 配置 DSN 的完整操作

驱动装好之后，你还需要在 Windows 里配置一个“数据源名称”，也就是 DSN。很多教程跳过了这一步，导致 Access 里连接 MySQL 时怎么都看不到目标数据库。

打开 ODBC 数据源管理器有个隐蔽的坑。在 Windows 搜索框直接输入“ODBC”，通常会搜出两个结果，一个叫“ODBC 数据源(64 位)”，一个叫“ODBC 数据源(32 位)”。它们对应的是两个不同的可执行文件：

• C:\Windows\System32\odbcad32.exe 是 64 位管理器
• C:\Windows\SysWOW64\odbcad32.exe 是 32 位管理器

注意这里 Windows 的命名很反直觉，System32 里放的是 64 位程序，SysWOW64 里才是 32 位程序。如果你装的是 32 位驱动，却打开 64 位管理器，驱动列表里自然什么都没有。

打开管理器后，我习惯在“系统 DSN”里新建，因为系统 DSN 对所有用户生效，后面测试和排障都方便。点击“添加”，选择“MySQL ODBC 8.0 Unicode Driver”，填这几项：

• Data Source Name：自己起一个，比如 mysql_test
• TCP/IP Server：127.0.0.1
• Port：3306
• User：root
• Password：你自己设的密码
• Database：目标库名

填完后点“Test”按钮，如果显示 Connection successful，这个 DSN 就能用了。接下来不管你是从 Access 里选“ODBC 数据源”还是从 Excel 里导入外部数据，都能在列表里看到它。

2.3 Access/Excel 连接 MySQL 的“64 位驱动”报错是怎么回事

网上很多人在 Access 里连接 MySQL 时，会遇到这样一句提示：“请先安装 Access 数据库 64 位系统驱动程序”。这个提示看起来像是 Access 缺了个驱动，但真相往往不是缺，而是位数根本不匹配。

我见过太多次这样的场景：Windows 是 64 位系统，Office 也是 64 位版本，Access 里选择“外部数据 — 新增数据源 — ODBC 数据库”，结果弹出需要 64 位驱动；手动去官网装了 64 位 MySQL ODBC，回来再看还是报错。

排查思路其实很简单。第一，确认 Access 的位数，路径是“文件 — 账户 — 关于 Access”，里面会明确写 32 位还是 64 位。第二，确认 ODBC 管理器里能看到对应位数的 MySQL 驱动。第三，如果报错反复出现，卸载驱动重装，装完后一定要在对应位数的 ODBC 管理器里确认驱动可见。

还有一种衍生报错是“64 位引擎不支持 DBC 数据，只支持 Access 数据”。这通常是因为系统里混装了 32 位和 64 位的 Access Database Engine 组件。Office 的 Access 引擎不允许 32 位和 64 位混装，一旦出现冲突，它连 MySQL 的 ODBC 路径都会被挡住。解决办法是统一 Office 和 Access 引擎的位数，别让两个版本同时存在。

3. 连不上 MySQL 8.0？认证协议不匹配的完整排障过程

3.1 现象：三个不同工具报出同一类错误

在 MySQL 8.0 刚发布那几年，我几乎每周都能收到类似的求助。Navicat 里弹出来的是：

code复制Client does not support authentication protocol requested by server; consider upgrading MySQL client

Delphi 的 FireDAC 里报的是：

code复制FireDAC phys MySQL client does not support authentication protocol requested

Java 项目里报的则是：

code复制The server requested authentication method unknown to the client [caching_sha2_password]

这三个报错看起来完全不一样，但它们的根因是同一个：MySQL 8.0 改了默认的用户认证插件，而客户端驱动的版本太旧，不认识新的认证协议。

3.2 根因：MySQL 8.0 换了默认认证插件

MySQL 5.7 及更早的版本，默认认证插件是 mysql_native_password，几乎所有驱动都支持。到了 MySQL 8.0，官方把默认认证插件换成了 caching_sha2_password，密码散列方式更安全，但也意味着所有客户端驱动必须能识别这个插件，才能完成握手。

如果你的驱动是 2018 年之前发布的版本，或者是基于老版 libmysql.dll 封装的，它对 caching_sha2_password 就完全没有概念，握手阶段直接失败。所以这不是密码输错了，也不是端口不通，而是认证方式对不上。

排查时先在命令行里登录 MySQL，执行这句 SQL：

sql复制SELECT user, host, plugin FROM mysql.user;

如果结果里你的登录用户对应的是 caching_sha2_password，基本就坐实了根因。

3.3 修复方案：改服务端认证方式 or 换驱动

解决这个问题有两条路。

第一条路，升级驱动，这是更推荐的方向。Navicat 升级到新版本，Java 项目把 mysql-connector-j 升到 8.0.13 以上，ODBC 驱动换到 8.0.x，FireDAC 换成支持 libmysql 8.0 的版本。新驱动都已经实现了 caching_sha2_password，连接不会再有问题。

第二条路，把用户的认证方式改回 mysql_native_password。应用在某些旧工具不好升级的生产环境里，不改工具，只改用户：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
FLUSH PRIVILEGES;

不推荐直接改 root，更稳妥的做法是给应用单独建一个账号：

sql复制CREATE USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongP@ss123';
GRANT ALL PRIVILEGES ON mydb.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

这样不会影响全局安全策略，也不会让 root 的认证方式被降级。等以后所有客户端都升级到新驱动，再切回 caching_sha2_password 也不迟。

3.4 顺手解决 Public Key Retrieval is not allowed

和认证插件同源的，还有一个非常常见的 JDBC 报错：“Public Key Retrieval is not allowed”。很多人第一次遇到时完全摸不着头脑。

原因是这样的：caching_sha2_password 在非 SSL 连接下，需要从服务器获取 RSA 公钥来加密传输密码，而 JDBC 驱动默认不允许自动检索公钥。要解决，只需要在连接串里加一个参数：

text复制jdbc:mysql://127.0.0.1:3306/testdb?useSSL=false&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true 的作用就是允许客户端自动向服务端索要公钥。本地开发环境通常直接加这个参数，但生产环境如果走非 SSL，要意识到中间人风险；有条件还是上 SSL 或者加固网络安全。

4. 连接串参数与性能调优：驱动只是第一步

4.1 JDBC 连接串里最容易被忽略的三个参数

驱动装好了，能连上了，不代表就万事大吉。连接串里有些参数不写，你会在正式跑业务的时候踩到莫名其妙的坑。

第一个是 serverTimezone。老版本 Connector/J 连接 MySQL 8.0 时，如果不指定时区，会报“The server time zone value ... is unrecognized”。因为 MySQL 8.0 默认使用系统时区，而 JDBC 驱动无法自动推断，需要你显式告诉它：

text复制jdbc:mysql://127.0.0.1:3306/testdb?serverTimezone=Asia/Shanghai

第二个是 useSSL。MySQL 8.0 默认开启了 SSL 相关能力，但开发环境通常没有配置证书，驱动尝试 SSL 握手时反而会失败。开发环境可以显式关闭：

text复制jdbc:mysql://127.0.0.1:3306/testdb?useSSL=false

第三个是 characterEncoding。中文乱码问题排查到最后，十有八九在这里。Java 连接串里加上 UTF-8 指定，并确保数据库、表、连接三层字符集一致：

text复制jdbc:mysql://127.0.0.1:3306/testdb?characterEncoding=utf8mb4

还有一个批处理参数 rewriteBatchedStatements=true，如果你的代码用了 addBatch/executeBatch，这个参数能把多条插入合并成一条网络请求，性能提升非常明显。

4.2 ODBC 的 DSN 与无 DSN 连接串

ODBC 连接其实有两种方式，很多人只会在图形界面里配 DSN，但程序里经常会用到无 DSN 连接串。

DSN 方式就是前面在 ODBC 数据源管理器里配置好的数据源，Access、Excel 里可以直接选。好处是集中管理，改一次 DSN 所有引用它的程序都生效。但缺点是换一台机器就要重新配。

无 DSN 连接串则是在程序代码里直接把驱动名和参数都写清楚：

text复制Driver={MySQL ODBC 8.0 Unicode Driver};Server=127.0.0.1;Port=3306;Database=testdb;User=root;Password=123456;Option=3;

这种方式的优点是配置全在代码里，部署到哪里都一样。注意驱动名必须和系统里安装的那个 ODBC 驱动完全一致，比如可能是“MySQL ODBC 8.0 Unicode Driver”或“MySQL ODBC 8.0 ANSI Driver”，写错一个字就找不到驱动。

4.3 连接池、超时与驱动的配合

数据库连接的建立本身就是网络传输加握手加认证的过程，非常费时。生产环境里几乎不会每执行一条 SQL 就新建连接，而是会用连接池管理连接。

Java 里最常见的连接池是 HikariCP，配合 Spring Boot 时配置大概是这样的：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000
      validation-timeout: 5000

这里驱动的作用是提供底层的 Connection 对象，连接池负责把这些对象管起来复用。很多时候高并发下出现连接超时或连接被重置，排查到最后是驱动版本太旧，跟 MySQL 8.0 的某些特性不兼容。比如连接被服务端清理后，旧驱动没有及时感知，连接池还把一个失效连接发给应用。这种情况下连接池配置怎么调都没用，升级驱动才是正解。

5. 驱动安装与卸载的隐藏陷阱：现场复盘

5.1 装上驱动却在 ODBC 管理器里找不到

这大概是继“连不上 MySQL”之后，出现频率第二高的问题。驱动装好了，打开 ODBC 管理器，驱动列表里却空空如也。

原因我前面提了一句，这里细说。很多人在 Windows 搜索框输入“ODBC”，有时会打开 32 位管理器，有时是 64 位，取决于搜索结果和点击的位置。如果装的是 64 位驱动，但打开的是 32 位管理器，自然看不到。要验证当前管理器到底是哪个位数，可以关掉再打开，看标题栏有没有“32 位”字样，或者用命令行直接运行指定路径。

另一个可能原因是驱动虽然装了，但安装过程因为权限问题没有完全注册。右键“以管理员身份运行”安装包，重装一遍，再打开管理器检查。

5.2 安装失败、残留与清理

MySQL ODBC 驱动安装失败的情况也时有发生，最常见的提示是“另一个版本已安装”或者“无法访问 Windows Installer 服务”。

这种问题通常是旧版本驱动没卸干净。清理思路值得记一下：先去“控制面板 — 程序和功能”卸载现有版本，然后删除安装目录，默认在 C:\Program Files\MySQL 或 C:\Program Files (x86)\MySQL 下面。如果还有残留，打开注册表编辑器，检查这两处路径：

• HKEY_LOCAL_MACHINE\SOFTWARE\MySQL：64 位安装的注册信息
• HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MySQL：32 位安装的注册信息

把残留的 MySQL Connector ODBC 相关键值删掉，再重新安装。操作注册表前一定要备份，改错了可能影响其他软件。我个人的习惯是先用系统自带的“卸载程序”走一遍，再去看注册表，大部分问题第一步就能解决。

5.3 驱动与服务端版本错配的真实经历

最后分享一个我实际遇到过的案例。客户的服务器是 MySQL 5.6，某 BI 报表工具通过 ODBC 连接。客户觉得新驱动更稳妥，就自作主张装了 8.0 版 Connector/ODBC。结果报表工具在导出数据的时候，timestamp 字段总是被读成字符串，日期格式全部错乱。

折腾了半天，最后把驱动换回 5.3 版本就好了。原因不是 8.0 驱动连不上 5.6，而是那款 BI 工具对 ODBC 元数据的解释逻辑还停留在老驱动时代，新驱动某个字段属性的返回方式变了，工具就理解不了了。

这个案例给我的教训是：驱动版本并不是越新越好。新驱动连老服务端通常没问题，但老应用配新驱动反而可能出状况。合理的选择是，先看调用方软件的官方文档推荐哪个驱动版本，再用那个版本；没有明确推荐时，优先和服务端大版本匹配。

最后分享一个个人习惯：如果只是需要一个 GUI 工具连 MySQL 查数据，直接用最新版 Navicat 或 DBeaver 就行，它们内置了合适的驱动，不用折腾系统级 ODBC。真正需要手动安装驱动的场景，集中在 Java 开发环境的 JDBC jar、以及 Access/Excel/BI 工具的 ODBC 场景。只要先把“程序是什么位数、服务端是什么版本、驱动是什么版本、认证插件是否匹配”这四个问题理清楚，百分之九十的驱动问题都能自己解决。我这些年排查过的怪问题，最后基本都落在 32/64 位不匹配和 caching_sha2_password 这两个根因上。