连接池本身不提供安全能力，安全依赖客户端配置、MySQL服务端权限控制及网络隔离。需限定账号IP范围、禁用明文密码、启用SSL、匹配驱动与认证插件版本；HikariCP等应设connection-test-query或isValid()校验权限，max-lifetime须小于wait_timeout以避免失效连接复用，maximumPoolSize宜控制在MySQL max_connections的70%–80%区间。
连接池本身不提供安全能力，安全靠配置和权限控制
MySQL 服务端没有内置连接池，所谓“连接池安全”其实是客户端驱动或中间件（比如 HikariCP、aiomysql）在复用连接时，如何避免凭证泄露、连接劫持、权限越界等问题。安全不是靠池子大小或超时参数自动带来的，而是靠显式配置+最小权限原则+网络隔离共同实现的。
常见错误现象：Too many connections 频发却查不到真实并发；应用日志里反复出现 Access denied for user 但账号密码没错；连接被复用后执行了不该执行的 SQL（比如跨租户数据访问）。
- 数据库账号必须限定来源 IP 或子网，例如
'app_user'@'192.168.10.%'，禁止用'%'开放全网 - 连接字符串中严禁硬编码密码，应通过环境变量或密钥管理服务注入，且确保进程内存不被 dump 泄露
- 启用 SSL 连接（如 JDBC 加
?useSSL=true&requireSSL=true），尤其在跨 VPC 或公网场景下，否则连接池复用的连接可能被中间人窃听 - MySQL 8.0+ 默认认证插件是
caching_sha2_password，旧版驱动（如 mysql-connector-python < 8.0.16）会静默降级为mysql_native_password，导致握手失败或弱加密 —— 必须确认驱动版本兼容性
HikariCP 的 connection-test-query 不只是防失效，更是防权限漂移
很多团队只把 connection-test-query 当成“心跳”，其实它在安全层面有隐含作用：每次从池中取连接时执行一次 SELECT 1，会触发 MySQL 的权限校验流程。如果该连接此前被某个高权限事务污染（比如误执行了 SET SESSION sql_log_bin=0 或变更了用户变量），这次校验能重置会话状态，防止权限上下文残留。
MySQL 8.0.22+ 推荐改用 isValid()（底层走 COM_PING），比 SELECT 1 更轻量，且不走查询缓存、不触发慢日志记录。
- 务必设
connection-test-query=SELECT 1（或升级驱动后用isValid()），不能留空或注释掉 - 不要用
testOnBorrow=false来“提升性能”——省下的几毫秒换来的是连接复用时的权限失控风险 - 若业务需临时修改会话变量（如
SET time_zone='+08:00'），应在归还连接前显式重置，或使用initialization-fail-fast=true强制校验
连接池空闲回收必须匹配 MySQL 的 wait_timeout
wait_timeout 是 MySQL 服务端参数（默认 28800 秒），表示空闲连接多久后被主动断开。如果连接池没配 pool_recycle（Python）或 max-lifetime（HikariCP），就会出现“连接池以为连接还活着，MySQL 已经把它杀了”的情况，下次复用直接报 Lost connection to MySQL server during query。
这不是稳定性问题，是安全边界失效：断连后重连会重新走认证流程，但若连接池跳过这步（比如因未设检测），就可能复用一个已失效但未清理的连接句柄，绕过部分权限检查。
- HikariCP 中设
max-lifetime=25200000（即 7 小时），比默认wait_timeout少 1 小时，留出缓冲 - aiomysql 中必须传
pool_recycle=25200（单位秒），否则长连接必然断连后无法恢复 - 若 MySQL 已调小
wait_timeout（如设为 300 秒应对突发攻击），连接池对应参数必须同步下调，不能只改服务端
最大连接数设太高反而降低稳定性
盲目把 maximumPoolSize 设到 100+，看似“抗压”，实则放大故障影响面：一个慢查询卡住 1 个连接，100 个连接全卡住的概率远高于 16 个；同时 max_connections 超限后 MySQL 会拒绝新连接，但连接池仍不断尝试建连，触发大量 java.net.ConnectException 或 DNS 解析超时，拖垮整个应用线程池。
真正稳定的连接池，是让活跃连接数始终落在 MySQL max_connections 的 70%–80% 区间内，并留出余量给 DBA 后台维护连接。
- 先查
SHOW STATUS LIKE 'Threads_connected'看当前真实连接数，再定池子上限 - Spring Boot 默认
maximum-pool-size=10是合理起点，QPS > 200 且平均响应 > 100ms 时才考虑上调 - 必须配
connection-timeout=2000（2 秒），否则网络抖动会让线程卡死半分钟，引发雪崩
max-lifetime 和 wait_timeout 当成两个独立参数去调，其实它们必须形成时间链：池子主动淘汰 → MySQL 被动清理 → 应用层明确失败 → 重连重建权限上下文。 
