MySQL 8.0 与 Spring Boot 3 需协同调优：JDBC URL 必配 serverTimezone=Asia/Shanghai、useSSL=true（生产）、characterEncoding=UTF-8；连接池 maximum-pool-size ≤ max_connections×0.7；innodb_buffer_pool_size 设为内存70–80%；wait_timeout ≥ max-lifetime；JSON 字段需手动处理函数索引。
MySQL 8.0 的参数配置不能只看数据库本身，必须和 Spring Boot 3 的 JDBC 行为、连接池策略、时区处理、字符集传递联动调整。单独调优 innodb_buffer_pool_size 或改几个 my.cnf 参数，大概率导致连接失败、乱码、时区错位或批量写入性能不升反降。
Spring Boot 3 默认驱动与 URL 必须匹配 MySQL 8.0 协议
Spring Boot 3（基于 JDK 17+）强制使用 com.mysql.cj.jdbc.Driver，且 JDBC URL 中的参数缺失或错误会直接抛出异常，不是静默降级。
-
serverTimezone是硬性要求：不设或设错（如GMT+8）会报java.time.format.DateTimeParseException；推荐用Asia/Shanghai而非UTC，避免开发/生产时区不一致 -
useSSL=false在本地开发可接受，但生产环境若启用了 MySQL TLS，则必须配useSSL=true&trustCertificateKeyStoreUrl=file:...，否则连接被拒绝 -
characterEncoding=utf8无效 —— MySQL 8.0 已废弃utf8别名，必须用UTF-8；同时要确保数据库、表、列的默认字符集是utf8mb4，否则 emoji 或四字节字符存入后变成??? - 批量插入必须显式启用：
rewriteBatchedStatements=true，否则JdbcTemplate.batchUpdate()或 MyBatis-Plus 的saveBatch()仍是逐条执行
连接池参数需与 MySQL 的 max_connections 对齐
Spring Boot 3 默认用 HikariCP，它的 maximum-pool-size 若超过 MySQL 的 max_connections，会导致新连接被拒绝，错误信息是 Too many connections，而不是超时。
- 查 MySQL 当前限制：
SHOW VARIABLES LIKE 'max_connections';（默认通常为 151） - HikariCP 推荐配置（以 16GB 内存服务器为例）：
spring.datasource.hikari.maximum-pool-size=30spring.datasource.hikari.minimum-idle=5spring.datasource.hikari.idle-timeout=30000spring.datasource.hikari.max-lifetime=1800000 - 若应用有定时任务或异步线程大量开连接，
maximum-pool-size建议 ≤max_connections × 0.7，预留空间给 DBA 操作或监控连接 - 别忽略
connection-timeout：设太短（如 1000ms）在高延迟网络下易误判连接失败；设太长（>30s）会让请求卡住很久才响应
MySQL 服务端关键参数必须同步调优
仅调客户端没用。比如 JDBC 开了 cachePrepStmts=true，但 MySQL 的 precautionary 相关参数未开，预编译缓存就形同虚设。
-
innodb_buffer_pool_size：设为物理内存的 70–80%，但 Spring Boot 应用本身也要吃内存，JVM 堆（-Xmx）和缓冲池加起来别超总内存 90% -
max_connections：至少设为2 × (HikariCP maximum-pool-size + 应用线程数)，留出后台连接余量 -
wait_timeout和interactive_timeout：建议 ≥HikariCP max-lifetime（单位秒），否则连接可能被 MySQL 主动断开，而 HikariCP 还以为它活着，下次用时报Connection is closed -
innodb_log_file_size：设大些（如 1G–2G），配合 Spring Boot 高频事务提交，减少 checkpoint 频率；但修改该值需停库、删旧日志、重启，不能热更新
JSON 字段 + 函数索引需绕过 ORM 的“透明”陷阱
Spring Boot 3 + MyBatis-Plus 读写 MySQL 8.0 的 JSON 类型字段时，默认会转成字符串，丢失路径查询能力；更隐蔽的问题是：函数索引（如 CREATE INDEX idx_theme ON user_config ((json_unquote(json_extract(config, '$.theme'))));）在 JPA/Hibernate 中无法被自动识别，必须手写 @Query 或 XML SQL 才能命中。
- 实体类中 JSON 字段类型建议用
String或JSONObject（Jackson），不要用Map，否则序列化/反序列化易错位 - MyBatis-Plus 的
Wrapper无法解析config->>'$.theme'这种表达式，必须用apply("config->>'$.theme' = {0}", "dark")手动拼 - 函数索引列名在
EXPLAIN中显示为generated column，若发现没走索引，先确认是否用了->（返回 JSON）而非->>（返回去引号字符串），后者才能匹配函数索引
最常被跳过的点是 wait_timeout 和 max-lifetime 的时间对齐，以及 JSON 字段在 ORM 层的“黑盒化”——你以为写了 @TableField 就万事大吉，其实查询逻辑早被框架重写了。调参不是填数字，是让每一层的生命周期、编码约定、协议语义严丝合缝咬在一起。
