简介：这是一份面向VB.NET初学者的MySQL连接示例工程，核心演示数据库连接与注册登录模块的实现。压缩包共15个文件，主要包含7个VB源码文件、2个资源描述文件，以及项目配置、解决方案等管理文件，覆盖窗体设计、项目配置与资源定义，整体仅17KB，结构精简便于快速查阅。已有215人浏览学习，适合正在练习桌面端数据库应用开发的读者，也可用于课程设计或毕业设计的前期参考。通过该工程可直观理解MySQL连接的调用方式、登录校验流程及关闭连接的资源释放逻辑；同时，描述中提到的mysql_connect属于PHP旧式接口，本项目实际以VB.NET方式组织，可结合官方驱动进行现代化改造，并将数据库凭据移入配置文件以增强安全性。观阅源码后，可以梳理出连接初始化、SQL执行与异常处理三个关键环节，进一步掌握参数化查询和最小权限分配等实践要点，为后续独立开发数据管理类桌面应用打基础。
1. 解压 MySQL_Connection_Project 后第一件事：先搞懂连接层在解决什么问题
接手过不少下载下来的 MySQL 连接项目，最常见的情况是：解压一个名为 MySQL_Connection_Project 的压缩包，里面配好了驱动、写好了示例代码，结果在自己机器上一跑，先报 Access denied，再报 Public Key Retrieval is not allowed，最后换掉密码又报 Communications link failure。问题几乎都不在业务代码里，全卡在连接这一层。
这个标题点到的核心就一件事：MySQL 连接。它指的是应用程序通过驱动与 MySQL 服务端建立会话、完成认证、协商字符集和事务状态的全过程，不只是一条 mysql -u root -p 命令。连接项目存在的意义，就是把这一层从业务代码里剥出来，统一管驱动、管参数、管重连，让上层只关心 SQL。
适合刚接触 MySQL 连接、想把手头示例项目跑起来的开发者，也适合被连接池和超时参数反复困扰的熟手。下面按「连接项目该有什么 → 最小可跑代码 → 参数怎么调 → 高频坑怎么避 → 怎么连得稳」的顺序讲，每段代码都能直接照抄复现。
2. 连接层项目该有哪些模块：驱动选型、参数清单与工程结构
2.1 为什么连接层值得单独做一个项目
先回答一个可能被忽略的问题：连接这么简单的事，为什么要单独做一个项目？很多初学者直接把连接代码写在业务模块里，每个文件里 new 一个 Connection，用完不关。这种写法在本地跑通没问题，一旦部署到服务器、接入多个环境，立刻失控。
我接手过一个内部系统的改造，原代码里连接 MySQL 的逻辑散落在十几个文件中，有人用 mysqli、有人用 PDO、有人直接在拼 SQL 时顺便连库。后来数据库要迁移到新主机、换端口和账号体系，改配置成了一场灾难——每处代码都要单独改，漏掉一处线上就报错。重构时我们把连接层收敛成一个独立模块，对外只暴露一个获取连接的方法，所有驱动加载、参数读取、连接池管理全部收口。之后再换库，只需要改一处配置文件。
还有一个容易忽视的点：连接的建立是有代价的。一次完整的连接建立包括 TCP 三次握手、MySQL 协议握手、认证、字符集协商，本地可能只要几毫秒，跨网络几十毫秒。每个业务请求都新建连接，数据库的线程和内存开销会成倍上升。连接池之所以是标配，根子就在这里。连接层项目把连接池纳入管理，本质上是用少量常驻连接支撑大量业务请求。
连接层项目至少要包含以下职责：
- 驱动加载与初始化：不同语言的驱动机制不同，Java 需要显式加载驱动类，Python 需要安装对应包，Node.js 需要选择同步或异步 API。
- 连接参数管理：主机、端口、用户名、密码、库名、字符集、超时、SSL 开关，集中放在配置文件里，而不是散落在代码中。
- 连接生命周期：包括建立、复用、释放、关闭，避免泄漏。连接是稀缺资源，用完不关是生产环境最常见的事故源之一。
- 故障恢复：断线检测、重连、连接池回收失效连接。
- 可观测性：至少能查当前连接数、最近一次连接耗时、失败原因。
把连接层独立出来，本质上是把「怎么连」和「连上之后干什么」分开。业务代码只关心 SQL 和事务，不关心驱动版本、认证插件、网络超时这类基础设施问题。
2.2 驱动选型：不同语言各有什么选择
连接项目的第一个决策是选驱动。不同语言的生态差异很大，这里给一个基于实战的选型表：
| 语言 | 常用驱动 | 特点 | 适用场景 |
|---|---|---|---|
| Python | PyMySQL | 纯 Python 实现，安装简单，依赖少 | 快速脚本、内部工具 |
| Python | mysql-connector-python | MySQL 官方驱动，功能全面 | 需要官方支持的项目 |
| Java | MySQL Connector/J | 官方 JDBC 驱动 | 绝大多数 Java 服务 |
| Node.js | mysql2 | 支持 promise、预处理语句、连接池 | 新 Node 项目首选 |
| Node.js | mysql | 老牌驱动，回调风格 | 遗留项目 |
| PHP | mysqli / PDO_MySQL | 内置扩展 | PHP 项目 |
选型时我的判断标准有三个。第一，是否官方维护，官方驱动的兼容性测试最全，版本升级时坑最少。第二，是否支持当前项目的并发模型，比如 Node.js 里 mysql2 的 promise 接口比 mysql 的回调接口更容易写出可维护的异步代码。第三，依赖体积和安装成本，在离线环境或精简容器里，纯 Python 的 PyMySQL 比需要编译的驱动省事得多。
举个例子区分一下。写一个每天跑一次的定时脚本，PyMySQL 就够了，不需要池；写一个高并发的 Web 服务，Java 用 HikariCP 管理 Connector/J 连接，Node.js 用 mysql2 自带池。这个区分决定了代码里是每次请求新建连接还是从池里借连接，代码结构完全不同。
2.3 连接参数清单：一个连接串里到底有什么
无论哪种语言，连接 MySQL 都要提供一组核心参数。把这些参数理清楚，后面排错会省很多时间。
| 参数 | 常见默认值 | 作用 | 典型坑 |
|---|---|---|---|
| host | 127.0.0.1 | 服务端地址 | 部分客户端对 localhost 走 Unix socket，与 TCP 行为不同 |
| port | 3306 | 服务端端口 | 改了端口但连接串没改 |
| user | 无 | 认证用户名 | 权限不足时 Access denied |
| password | 无 | 认证密码 | 含特殊字符需要转义或 URL 编码 |
| database | 无 | 默认库 | 库名写错报 Unknown database |
| charset | utf8mb4 | 字符集协商 | 用 utf8 存 emoji 会报错 |
| connect_timeout | 10s | 建连超时 | 网络不通时客户端会挂很久 |
| ssl_mode / useSSL | 因驱动而异 | 是否启用加密传输 | 开启后证书不匹配报错 |
多说一句 host 的写法。MySQL 命令行客户端在 Unix 系统下，localhost 默认走 Unix socket，而 127.0.0.1 强制走 TCP。如果服务端只监听了 TCP 端口、或者 socket 文件路径不对，用 localhost 就会连接失败。排查连接问题时，第一件事就是把 host 统一改成 127.0.0.1，排除 socket 路径的干扰。
密码含特殊字符时有个暗坑。JDBC URL 里的密码如果包含 &、?、# 这类字符，必须做 URL 编码，否则会被当成参数分隔符或锚点。比如密码是 Pass&123，URL 里要写成 Pass%26123。PyMySQL 和 mysql2 因为是传参而不是拼 URL，没有这个问题。这也是我偏好传参写法而非连接串写法的一个原因。
2.4 一个典型连接项目的文件结构
如果你手上只有压缩包没有文档，先按下面的结构核对它是不是一个完整的连接项目：
MySQL_Connection_Project/ ├── config/ │ └── db_config.ini # 连接参数集中管理 ├── src/ │ ├── db_connection.py # 连接封装模块 │ └── query_example.py # 查询示例 ├── requirements.txt # Python 依赖清单 └── README.md # 使用说明我一般会在 config 里放一个独立的配置文件，而不是把参数硬编码在代码里。理由很简单：开发环境、测试环境、生产环境的 host、密码、连接池大小都不一样，参数集中放，部署时只需替换配置文件。配置文件里只放非敏感参数，密码从环境变量读取。连接项目至少要保证：不写死、可替换、缺失时报错清晰。至于密码本身，连接项目里最常见的泄漏源就是硬编码密码，这一点无论项目多小都要守住。
3. 把 MySQL 连接跑通的最小代码：Python、Java、Node.js 三套命令级示例
3.1 准备环境：先确认服务端与驱动匹配
写连接代码之前，先花两分钟确认三件事：服务端在跑、端口能通、账号存在。跳过这一步，后面所有的报错你都会怀疑是代码问题，其实环境根本没就绪。
用命令行客户端确认服务端状态：
mysql -u root -p -h 127.0.0.1 -P 3306进入后执行：
SELECT VERSION(); SHOW VARIABLES LIKE 'port';第一条确认版本，第二条确认监听端口。如果连接失败，先确认服务端进程是否启动，再看防火墙是否放行了端口。这里顺带说一句版本匹配：高版本驱动通常兼容老版本服务端，但反过来不成立——MySQL 8.0 的认证插件在老驱动下可能不工作。如果你用的是老驱动且无法升级，见第 5 章的坑二；反过来，太新的驱动有时会对老服务端的某些特性报不支持，这时候优先升级服务端小版本，而不是降驱动。
接着创建一个专用测试账号，不要用 root 跑应用连接：
CREATE USER 'app_user'@'127.0.0.1' IDENTIFIED BY 'YourPass123'; CREATE DATABASE IF NOT EXISTS test_db DEFAULT CHARACTER SET utf8mb4; GRANT ALL PRIVILEGES ON test_db.* TO 'app_user'@'127.0.0.1'; FLUSH PRIVILEGES;这里 host 写 127.0.0.1，意味着只允许从本机 TCP 连接。如果应用跑在别的机器上，要改成对应网段的地址或用通配符，同时更新 MySQL 配置里的 bind-address。账号建好之后，下面的三套代码都拿这套账号测。
3.2 Python 最小连接代码：PyMySQL 版
Python 下我用得最多的是 PyMySQL，安装一句命令：
pip install pymysql最小连接代码：
import pymysql conn = pymysql.connect( host="127.0.0.1", port=3306, user="app_user", password="YourPass123", database="test_db", charset="utf8mb4", connect_timeout=5, ) try: with conn.cursor() as cur: cur.execute("SELECT 1") print("连接成功:", cur.fetchone()) finally: conn.close()逻辑说明：pymysql.connect 建立一个 TCP 连接并完成认证；cursor 用来执行 SQL；try/finally 确保连接一定会关闭。很多新手只写 try 不写 finally，一旦 SQL 抛异常，连接就泄漏了，连接数累计起来服务端直接拒绝新连接。
参数说明：connect_timeout=5 是建连超时，单位秒，网络异常时不会让进程挂太久；charset 必须写成 utf8mb4，写 utf8 的话插入 emoji 和生僻字会报错，详见第 4 章。如果连接失败，PyMySQL 会抛 OperationalError，里面包含错误码和文案，常见的 1045（认证失败）、1049（库不存在）、2003（连不上端口）分别对应第 5 章的坑一、坑三、坑四，把异常打出来看 errno 是最快的定位方式。
3.3 Java 最小连接代码：JDBC 版
Java 端需要引入 MySQL Connector/J 驱动。以 Maven 项目为例，在 pom.xml 里加依赖：
<dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>最小连接代码：
import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; public class MysqlConnect { public static void main(String[] args) throws Exception { String url = "jdbc:mysql://127.0.0.1:3306/test_db" + "?useSSL=false&serverTimezone=Asia/Shanghai&connectTimeout=5000"; try (Connection conn = DriverManager.getConnection(url, "app_user", "YourPass123"); Statement st = conn.createStatement(); ResultSet rs = st.executeQuery("SELECT 1")) { rs.next(); System.out.println("连接成功: " + rs.getInt(1)); } } }逻辑说明：DriverManager.getConnection 负责建立连接并完成认证；Java 7 的 try-with-resources 会自动关闭 Connection、Statement、ResultSet，比手动 finally 更稳。新版驱动不再要求显式 Class.forName 加载驱动类，但写上也无妨，老项目里常见。
参数说明：URL 里的 useSSL=false 表示本地测试不加密；serverTimezone 显式指定时区，否则高版本驱动会报 time zone 错误，这一条在踩坑章节会展开；connectTimeout=5000 是建连超时毫秒数。注意 JDBC URL 的参数用 & 连接，这是最容易写错的地方——换成 Python 的写法用逗号或分号，驱动直接不认。
3.4 Node.js 最小连接代码：mysql2 的 promise 版
Node.js 端推荐 mysql2，它的 promise 接口比老 mysql 包的回调地狱好维护得多：
npm install mysql2const mysql = require('mysql2/promise'); async function main() { const conn = await mysql.createConnection({ host: '127.0.0.1', port: 3306, user: 'app_user', password: 'YourPass123', database: 'test_db', connectTimeout: 5000, }); const [rows] = await conn.query('SELECT 1'); console.log('连接成功:', rows[0]['1']); await conn.end(); } main().catch((err) => { console.error('连接失败:', err.message); process.exit(1); });逻辑说明：mysql2/promise 返回的 createConnection 是异步的，用 await 拿到连接对象；query 方法返回 [rows, fields] 结构，解构赋值取行数据；conn.end() 显式释放连接，脚本里不调它进程可能挂着不退出。
参数说明：connectTimeout 与 Python 一样是建连超时，单位毫秒。如果想共用连接，推荐用 mysql2 的 createPool 而不是 createConnection，连接池参数在第 4 章讲。Node.js 的坑在于回调版 mysql 包的 query 结果格式和 promise 版不一样，换驱动时别忘了同步改取值的写法。
三套代码跑通之后，你已经完成了连接项目最核心的部分。接下来真正考验配置功底的是参数调优——连得上只是及格，连得稳才是要点。
4. 连接参数调优：字符集、超时、SSL 与连接池的数值怎么定
4.1 字符集：utf8mb4 才是完整的 UTF-8
字符集是连接层最常见的隐性坑。MySQL 里的 utf8 最多存 3 字节，而真正的 UTF-8 需要 4 字节，像 emoji 和部分生僻汉字都是 4 字节。用 utf8 字符集去连、去建表，插入这些字符时要么直接报错，要么被存成问号。
连接层的字符集参数决定的是客户端与服务端之间传输的编码，它和表的字符集是两回事。正确做法是三层一致：
- 连接参数指定 charset=utf8mb4（Python）或 characterEncoding=UTF-8（JDBC URL）；
- 建库建表时指定 DEFAULT CHARACTER SET utf8mb4；
- 服务端配置文件里 character_set_server 设为 utf8mb4。
对应的排序规则也要一起定。MySQL 8.0 默认的 utf8mb4_0900_ai_ci 附带更完整的 Unicode 排序，但只在 MySQL 8 可用；如果服务端是 5.7，用 utf8mb4_general_ci 或 utf8mb4_unicode_ci 更稳妥。排序规则不一致的典型症状是联表查询报 Illegal mix of collations 错误，此时要检查连接字符集和表字符集是否打架。
注意：连接字符集只影响传输编码，不代表表数据自动转换。表结构本身是什么字符集，连接层无法改变，所以建表时的字符集决定权更大。
4.2 超时参数：connect_timeout、wait_timeout 与连接保活
超时是最容易被忽略、上线后才暴露的参数组。它分两个方向：客户端建连超时和服务端空闲超时。
客户端侧，connect_timeout 控制建立 TCP 连接和完成认证的总耗时上限。Python 里是秒，JDBC URL 和 Node.js 里是毫秒。建议都设成 3 到 5 秒，别用默认的 10 秒以上，否则数据库故障时应用请求会全部堆积在等待连接上，拖垮整个服务。
服务端侧，超时相关变量有多个，放在一起看更清楚：
| 参数 | 方向 | 常见默认值 | 作用 |
|---|---|---|---|
| connect_timeout | 服务端 | 10s | 服务端等待客户端握手完成的超时 |
| wait_timeout | 服务端 | 28800s | 非交互连接空闲超时 |
| interactive_timeout | 服务端 | 28800s | 交互式会话空闲超时 |
| net_read_timeout | 服务端 | 30s | 读取客户端数据超时 |
| net_write_timeout | 服务端 | 60s | 向客户端写数据超时 |
wait_timeout 默认 8 小时，表面够用，但配合网络中间设备（防火墙、负载均衡）的空闲回收策略，实际空闲超过 2 到 5 分钟就可能被掐断。连接池里的连接长时间没被使用，下次取出时已经是死连接，报 Communications link failure 或 Connection is not available。
解决思路是三层配合：连接池设空闲检测（取出前验证）、应用层做断线重连、服务端适当调 wait_timeout。数值上我一般把服务端 wait_timeout 设成 1800 秒（30 分钟），连接池空闲连接最大存活时间设成小于它的值，保证池里的连接永远比服务端先一步续命或重建。
4.3 SSL 与安全连接：本地开发与生产的不同选择
SSL 的取舍取决于网络环境。本地开发、单机调试，开不开都行，开了反而要处理证书，JDBC 里直接 useSSL=false 省事。应用与服务端跨网络传输时，必须开启加密，否则用户名密码和 SQL 内容都是明文。
JDBC 8.0 之后的写法是 sslMode 参数，取值 DISABLED、REQUIRED、VERIFY_CA、VERIFY_IDENTITY。前两个好理解，VERIFY_CA 是校验服务端证书链，VERIFY_IDENTITY 在 VERIFY_CA 基础上再校验主机名。生产环境建议至少 VERIFY_CA，需要把 CA 证书放到应用侧并指定 trustStore。
Python 侧 PyMySQL 的 ssl 参数是一个字典，可以传 ca、cert、key 三个文件路径：
conn = pymysql.connect( host="127.0.0.1", user="app_user", password="YourPass123", database="test_db", ssl={"ca": "/path/to/ca.pem", "cert": "/path/to/client-cert.pem", "key": "/path/to/client-key.pem"}, )参数说明：ca 是 CA 证书路径，用于校验服务端身份；cert 和 key 是客户端证书和私钥，服务端要求双向认证时才需要。不需要双向认证时只传 ca 即可。MySQL 8.0 开启了 require_secure_transport 后，不加密的连接会被直接拒绝，报错信息里会带有 SSL 相关字样，此时按上面补证书配置。
4.4 连接池参数：最小连接数、最大连接数与空闲回收
生产环境几乎不会裸连。建连的成本不低——TCP 握手、认证、字符集协商，一次几百毫秒到一秒，高并发下裸连会让数据库被打满。连接池的意义就是复用。
连接池的参数是一个平衡问题。最大连接数开太大，数据库内存和线程开销扛不住；开太小，业务峰值时排队。常见的起步值是 min=5、max=20，观察业务峰值和数据库 Threads_connected 指标再调。有一个粗略公式可以参考：连接数 ≈ 核心数 × 2 + 磁盘数，但线上最靠谱的方式还是压测后看曲线。
Java 侧以 HikariCP 为例，核心参数：
maximumPoolSize=20 minimumIdle=5 connectionTimeout=30000 idleTimeout=600000 maxLifetime=1800000 validationTimeout=5000参数说明：connectionTimeout 是等待连接的最大毫秒数，池子空了之后请求最多等这么久；idleTimeout 是空闲连接被回收前的毫秒数，要小于服务端 wait_timeout；maxLifetime 是连接最大存活时间，必须小于数据库或网络设备的空闲回收时间，否则池里的连接可能被服务端先掐断；validationTimeout 是取出连接时做健康检查的超时。这几个值之间是连锁关系，改了一个要检查其他值是否仍然合理。
Node.js 侧 mysql2 连接池：
const mysql = require('mysql2/promise'); const pool = mysql.createPool({ host: '127.0.0.1', user: 'app_user', password: 'YourPass123', database: 'test_db', waitForConnections: true, connectionLimit: 20, queueLimit: 0, });参数说明：waitForConnections 表示池满时请求排队而不是报错；connectionLimit 是最大连接数；queueLimit 是排队上限，0 表示不限制。mysql2 的池没有内置空闲回收，需要在服务端 wait_timeout 之上做应用层保活，常见做法是定期执行 SELECT 1。这一点和 4.2 节说的问题直接相关，别等线上出现大量死连接再补救。
MySQL 服务端 max_connections 也要同步看。连接池 max 总和如果超过服务端 max_connections，池里的连接建不起来，会一直在池里重试。多实例部署时尤其要注意：10 个实例每个池 20 个连接，服务端至少要留 200 以上的余量。
5. MySQL 连接高频踩坑实录：从 Access denied 到连接超时的 5 个典型问题
这章是积累下来的血泪经验。前四章讲的是怎么连、参数怎么配，这一章讲的是连不上时怎么看报错。每条按「现象 → 原因 → 解决」写，遇到同款问题直接照做。
5.1 坑一：Access denied for user 'app_user'@'localhost'
现象：代码里账号密码看着都对，连接却报 ERROR 1045 Access denied for user 'app_user'@'localhost' (using password: YES)。
原因：三种情况最常见。一是密码确实不对；二是账号存在但 host 不匹配——你在 MySQL 里建的是 'app_user'@'127.0.0.1'，但客户端从 localhost 或别的 IP 发起连接，MySQL 按用户表里匹配不到的 host 拒绝；三是该账号对目标库没有权限，报错文案同样是 Access denied。
解决：先用命令行登录排查是密码问题还是 host 问题：
mysql -u app_user -p -h 127.0.0.1 -P 3306 test_db能登录说明密码没问题，回到 MySQL 里查用户表：
SELECT user, host, plugin FROM mysql.user WHERE user = 'app_user';看 host 列是否覆盖了你实际连接的来源地址。最常见的修法是补一个匹配来源的账号，或直接改为 '%'，但生产环境不建议用 '%' 放开所有来源，按实际网段建账号更安全。还要确认授权：
SHOW GRANTS FOR 'app_user'@'127.0.0.1';5.2 坑二：Public Key Retrieval is not allowed
现象：MySQL 8.0 上，Java 驱动第一次连接报 Public Key Retrieval is not allowed，Python 某些老版本驱动也会遇到类似问题。
原因：MySQL 8.0 默认认证插件是 caching_sha2_password。客户端第一次连接时，如果连接没走 SSL，服务端要求客户端先获取 RSA 公钥用于加密密码传输。部分驱动出于安全考虑默认不允许自动获取公钥，于是拒绝连接。
解决：两个方向。开发环境图省事，在 JDBC URL 里加 allowPublicKeyRetrieval=true，配合 useSSL=false 使用；生产环境建议把 useSSL 打开，走 SSL 加密后就不存在公钥获取问题。更稳妥的做法是给账号指定兼容旧版的认证插件：
ALTER USER 'app_user'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY 'YourPass123';注意：mysql_native_password 在 MySQL 8.0 里仍然可用，但新版 MySQL 已默认移除，新项目尽量别依赖它，优先用 SSL + caching_sha2_password 的组合。判断认证插件用上面坑一里的 SELECT user, host, plugin 查询即可。
5.3 坑三：Unknown database 或表名找不到的大小写问题
现象：连接参数里的 database 名与建库时一致，却报 Unknown database；或者连接成功、SQL 里写的表名与建表时大小写不同，报 Table doesn't exist。
原因：MySQL 的表名在 Linux 上是区分大小写的，受 lower_case_table_names 参数控制。该参数值为 0 表示区分大小写，1 表示不区分并转为小写存储。服务器初始化时定了就不能改，改了会导致数据文件访问异常。库名大小写则始终区分。
解决：先查服务端实际值：
SHOW VARIABLES LIKE 'lower_case_table_names';值为 0 时，SQL 里的库名、表名必须和建表时完全一致；值为 1 时统一用小写。连接参数里的 database 名也要严格按服务端实际库名写。这个坑的隐蔽之处在于本地开发机上 MySQL 默认不区分大小写，部署到 Linux 后立刻翻车。
5.4 坑四：Communications link failure 与 Connection timed out
现象：应用启动后连接报 Communications link failure，或 connect timed out，部分框架里常见的是 Can't connect to MySQL server on '127.0.0.1'。
原因：网络链路问题占多数。服务端 bind-address 只绑了 127.0.0.1 导致外部机器连不上；防火墙没放行 3306；云服务器安全组没配置；服务端实际端口不是 3306；客户端 connect_timeout 设太短，慢网络下握手没完成就超时。还有一种隐蔽场景：MySQL 服务端 max_connections 打满，新连接被拒绝，报错也会指向无法连接。
解决：按链路逐层排查。先在本机用命令行确认服务端正常；再在应用所在机器上测端口连通性：
nc -zv 127.0.0.1 3306注意：用 nc 测试端口时，看到 succeeded / Connected 即表示端口可达；不显示不代表服务端一定挂了，也可能是安全组或防火墙拦截。
能通，问题在认证或参数；不通，看服务端 bind-address、防火墙、安全组。同时查服务端连接数是否打满：
SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';Threads_connected 接近 max_connections 时，连接的报错基本就是连接数耗尽。临时调大 max_connections 只能缓解，根治要查连接是否泄漏、连接池是否过大。
5.5 坑五：The server time zone value 'XXX' is unrecognized
现象：Java 驱动连接 MySQL 8.0 报 The server time zone value '中国标准时间' is unrecognized or represents more than one time zone，或类似的时区值错误。
原因：MySQL 8.0 服务端时区默认是系统时区，某些系统返回的时区名 JDBC 驱动不认识，导致建连失败。这不影响业务逻辑，纯粹是驱动校验严格。
解决：JDBC URL 里显式指定 serverTimezone：
jdbc:mysql://127.0.0.1:3306/test_db?serverTimezone=Asia/ShanghaiPython 驱动一般没有这个参数，但连接后执行涉及时间的 SQL 时，要注意服务端 time_zone 变量和客户端本地时区的一致性。统一做法是在连接初始化时执行：
SET time_zone = '+08:00';用固定的偏移量而不是时区名，避免不同机器默认时区不一致导致的时间换算问题。
6. 从「能连上」到「连得稳」：连接自检、断线重连与监控的落地技巧
连接跑通只是第一步，线上连接挂掉是迟早的事——数据库重启、网络抖动、空闲回收，任何一个都能让连接失效。这一章给三个落地技巧，让连接层从能用变成扛得住。
第一个技巧是连接自检。无论用什么驱动，取出连接时先验证一下：
def check_connection(conn): try: with conn.cursor() as cur: cur.execute("SELECT 1") return True except Exception: return FalseSELECT 1 是开销最小的健康检查语句。连接池开启 validation 时，本质也是执行类似的探测。自检要放在取出连接之后、执行业务 SQL 之前，避免拿着一个死连接去跑业务查询，浪费一次完整的超时等待。
注意：自检语句 SELECT 1 不要放在事务里执行，避免干扰事务状态。
第二个技巧是断线重连。常见的做法是带退避的重试：
import time def connect_with_retry(host, user, password, database, retries=3, delay=2): for attempt in range(retries): try: return pymysql.connect( host=host, user=user, password=password, database=database, charset="utf8mb4", connect_timeout=5, ) except Exception: if attempt == retries - 1: raise time.sleep(delay * (2 ** attempt)) # 指数退避逻辑说明：第一次失败后等 2 秒，第二次等 4 秒，最多重试 3 次。指数退避比固定间隔重试更友好，避免数据库刚重启时大量客户端同时重连造成瞬间压力。重试只适合建连阶段，业务执行中的 SQL 失败要交给事务处理决定是回滚还是重放。
第三个技巧是监控连接状态。我一般会在运维脚本里定期执行下面两条：
SHOW STATUS LIKE 'Threads_connected'; SHOW PROCESSLIST;Threads_connected 反映当前总连接数，和 max_connections 对比能看到连接水位。SHOW PROCESSLIST 能看到每个连接来自哪个 IP、在跑什么 SQL、sleep 了多久。大量 Sleep 状态的连接说明连接池空闲连接过多或没及时回收，是配置失衡的信号。
这套组合拳打完，连接层才算真正稳定。回看这些年处理过的连接问题，十个里有七个是参数不一致、三个是环境不通，真正的驱动 bug 极少。所以排查时别急着怀疑驱动，按「环境 → 认证 → 参数 → 代码」的顺序查，效率最高。希望帮到你。
本文还有配套的精品资源，点击获取
