proxysql + mysql 8.0+ 生产环境可行，但须确保 proxysql ≥2.0.19 以原生支持 caching_sha2_password，否则需降级用户认证插件为 mysql_native_password 并禁用 ssl 握手。
MySQL 8.0+ 升级后 ProxySQL 报 Unknown database 或连接失败
ProxySQL 本身不校验后端 MySQL 版本，但升级到 MySQL 8.0+ 后，mysql_native_password 插件默认被禁用、caching_sha2_password 成为默认认证方式，而老版本 ProxySQL（如 2.0.18 之前）默认不支持该插件——导致添加节点时 INSERT INTO mysql_servers 成功，但运行时连接直接被拒绝，日志里出现 Access denied for user 或空连接。
实操建议：
- 确认 ProxySQL 版本 ≥ 2.0.19（官方从该版本起原生支持
caching_sha2_password）；低于此版本必须在 MySQL 主从库上显式执行ALTER USER 'proxysql'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; -
mysql_servers表中务必设置use_ssl=0（除非你已配好全链路 TLS），否则 MySQL 8.0+ 可能因 SSL 要求握手失败 - 升级后首次启动 ProxySQL，用
mysql -uadmin -p -h127.0.0.1 -P6032连管理接口，执行SELECT * FROM monitor.mysql_server_connect_log ORDER BY time_start_us DESC LIMIT 5;查看真实连接错误原因，别只信SHOW MYSQL SERVERS的Status列
MyCat 启动失败或 schema.xml 解析报错
MyCat 1.6.x 系列（主流生产版本）基于 JDK 8 编译，对 MySQL 8.0+ 的协议变更兼容性差：比如 MySQL 8.0.23+ 移除了 mysql.time_zone_name 表的本地时区支持，而 MyCat 初始化时会尝试查询该表；又比如 information_schema.COLUMNS 字段顺序微调，导致 MyCat 的元数据解析器抛 java.lang.ArrayIndexOutOfBoundsException。
实操建议：
- 不要跳过 MyCat 官方适配公告——MyCat 2.x（如 2.2.1+）才正式声明支持 MySQL 8.0.33+，1.6.x 用户必须打补丁或降级 MySQL 认证方式
-
schema.xml中所有<datanode></datanode>的database属性值，必须和 MySQL 8.0 实例中SHOW DATABASES返回的**实际名称完全一致（含大小写）**；MySQL 8.0 默认lower_case_table_names=0，库名大小写敏感，配错直接触发java.sql.SQLException: Unknown database 'xxx' - 检查
server.xml中sequnceHandlerType配置，若用0（本地文件序列），MySQL 8.0 的secure_file_priv限制可能导致nextid文件写入失败，建议切到1（数据库序列）
ShardingSphere-JDBC 连接池频繁 Connection reset
这不是中间件本身问题，而是 MySQL 8.0+ 默认启用了更严格的网络超时与协议安全策略：比如 wait_timeout=60（旧版常设为 28800），且 max_allowed_packet=4M（旧版常为 64M）。ShardingSphere-JDBC 若未显式配置连接池心跳或重连逻辑，会在空闲 60 秒后被 MySQL 主动断开，下次取连接时抛 Connection reset by peer。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
实操建议：
- 在 MySQL 服务端调整：
SET GLOBAL wait_timeout = 28800;并写入my.cnf的[mysqld]段；同时增大max_allowed_packet = 64M - 在 ShardingSphere 的
application.yml中启用连接验证：props: connection-timeout-milliseconds: 30000+idle-timeout-milliseconds: 600000+max-lifetime-milliseconds: 1800000，并确保validation-query: SELECT 1生效 - 避免用
spring.datasource.hikari.connection-test-query覆盖 ShardingSphere 自带的验证逻辑，二者冲突会导致验证失效
所有中间件共有的主从延迟误判风险
MySQL 8.0 引入了并行复制增强（slave_parallel_type=LOGICAL_CLOCK）、WRITESET 事务分发等机制，理论上降低延迟，但实际中：当主库批量写入带 UUID() 或 NOW() 的语句时，从库重放可能卡在某条非幂等 SQL 上；而 ProxySQL/MyCat/ShardingSphere 都依赖 Seconds_Behind_Master 值做延迟判断——但 MySQL 8.0 在 GTID 模式下，该值可能长时间显示 NULL 或 0，掩盖真实延迟。
这意味着：你以为“从库已追平”，中间件却把刚写入的数据查请求发过去，结果读不到。这个坑不在中间件配置里，而在你是否真正在监控 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的差值。
实操建议：
- 别只看
Seconds_Behind_Master；在 ProxySQL 中用monitor.mysql_server_replication_lag表查lag字段，它底层执行的是SELECT TIMESTAMPDIFF(SECOND, last_executed_timestamp, NOW())，比 SHOW SLAVE STATUS 更准 - 对强一致性读，坚持用 HINT：ProxySQL 认可
/*+ FORCE_MASTER */，MyCat 认可/*#mycat:db_type=master*/，ShardingSphere 认可/* sharding hint: write_ds */——这些注释必须紧贴SELECT开头，不能换行或有空格 - MySQL 8.0 的
replica_parallel_workers建议设为 CPU 核数 −1，但若业务存在大量小事务，反而会因调度开销加大延迟；上线前务必用sysbench --threads=32 oltp_read_write对比压测
