TiDB官方推荐使用mysql-connector-j 8.0.33+驱动，需配置serverTimezone、useTimezone、autoReconnect=false等关键URL参数，Spring Boot中应调优HikariCP连接池并避免在事务中执行DDL。
用哪个JDBC驱动连TiDB最稳
TiDB官方推荐用 mysql-connector-j（8.0.33+），不是 mysql-connector-java（已废弃）。老项目如果还在用 5.x 或 6.x 驱动，大概率会遇到 Unknown system variable 'tx_isolation' 或连接后查不出表名的问题——TiDB 6.0+ 已移除该变量，而旧驱动硬编码依赖它。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先选
mysql-connector-j:8.0.33或更高（Maven 中 groupId 是mysql，artifactId 是mysql-connector-j） - 避免用
com.mysql.cj.jdbc.Driver类名手动Class.forName()—— 现代 JDBC 4.0+ 自动发现，显式加载反而容易触发类加载冲突 - 若用 Spring Boot，确认
spring-boot-starter-jdbc版本 ≥ 3.1（对应底层驱动自动拉取较新版本）
URL里必须加的参数有哪些
TiDB 不是 MySQL 的完全副本，连接串漏掉关键参数会导致连接成功但行为异常，比如事务隔离级别错乱、时间字段解析失败、甚至 prepareStatement 报 ERROR 1105 (HY000): unknown error: [types:1292]Incorrect datetime value。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 强制指定时区：
?serverTimezone=Asia/Shanghai&useTimezone=true（不加可能让java.time.LocalDateTime写入变成 UTC 时间） - 禁用自动重连：
&autoReconnect=false（TiDB 不支持 MySQL 的重连语义，开它反而引发不可预测的连接中断） - 启用服务端预处理（可选但推荐）：
&useServerPrepStmts=true&cachePrepStmts=true，能显著提升批量写入性能 - 别加
zeroDateTimeBehavior=convertToNull—— TiDB 对0000-00-00处理方式不同，加了反而报错
Spring Boot里DataSource怎么配才不踩坑
很多人直接套用 MySQL 的 HikariCP 配置，结果在 TiDB 上出现连接池耗尽、事务超时、或 Connection is closed 异常。根本原因是 TiDB 的连接生命周期和事务模型与 MySQL 有差异：它没有真正的“长连接保活心跳”，且默认事务超时是 1 小时（MySQL 是 0 即不限制）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
spring.datasource.hikari.connection-timeout设为30000（30 秒），太短易误判，太长阻塞线程 -
spring.datasource.hikari.validation-timeout必须 ≤connection-timeout，否则校验永远等不到响应 - 禁用
spring.datasource.hikari.leak-detection-threshold（TiDB 连接关闭延迟高，开它会频繁报“连接泄漏”误告） - 如果应用大量使用 savepoint，记得设
spring.datasource.hikari.allow-pool-suspension=true，否则嵌套事务回滚可能卡死
为什么执行DDL总卡住或报错
TiDB 的 DDL 是在线异步执行的，ALTER TABLE 不会锁表，但 JDBC 默认把 DDL 当作普通语句同步等待——这会导致连接卡在 executeUpdate() 几分钟不动，或者抛出 ERROR 9001 (HY000): PD server timeout。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有 DDL 操作前，显式设置
connection.setAutoCommit(true)（确保不在事务里执行 DDL） - 用
Statement.execute()而非executeUpdate()，后者对 DDL 返回值判断逻辑与 TiDB 不兼容 - 如果要等 DDL 完成再继续，改用 TiDB 提供的
ADMIN SHOW DDL JOBS查询状态，而不是靠 JDBC 阻塞等待 - 开发环境慎用 Flyway/Liquibase 的
repair功能——TiDB 的 schema version 记录方式与 MySQL 不同，修坏了得手动清flyway_schema_history表
真正麻烦的是跨大版本升级后的兼容性断层，比如从 TiDB 5.4 升到 7.5，utf8mb4 排序规则默认值变了，老连接串没加 &collation=utf8mb4_bin 就可能查不出数据。这种细节不会报错，只会静默失效。
