MySQL Router是MySQL官方推出的轻量级中间件，它位于应用程序和MySQL服务器之间，负责将数据库连接请求转发到合适的后端节点。它最典型的使用场景是配合MySQL InnoDB Cluster实现高可用架构：当集群中的主节点发生故障时，Router能在秒级感知并把写请求切到新的主库，应用程序完全无感知。很多刚接触MySQL高可用方案的开发者容易把它和MySQL Proxy搞混，或者不清楚它到底解决了什么问题，下面我们从原理、配置到实际部署完整梳理一遍。
MySQL Router的核心原理与工作模式
MySQL Router本质上是一个TCP代理程序，它不解析SQL语句的具体内容，也不做SQL优化，它只关心连接层面的路由。启动后，Router会在本机监听若干端口，应用程序像连接普通MySQL一样连接这些端口，Router再把连接转发给后端的真实数据库节点。这种设计让它的开销非常小，转发性能接近直连。
Router默认提供两类端口策略。第一类是读写端口（read-write），通常监听6446端口，所有发到这个端口的连接都会被路由到集群的当前主节点，也就是拥有写权限的那个节点。第二类是只读端口（read-only），通常监听6447端口，连接会被路由到从节点，用于分担读压力。如果集群配置了多个从节点，Router会在它们之间做轮询分发。
除了这两个默认端口，Router还支持一种单端口模式，也就是把读写和只读合并到同一个端口上，通过connection routing结合元数据服务器来判断请求类型。需要注意的是，这种模式下Router并不分析SQL语义，它只识别连接时指定的读写属性，所以如果你在只读端口上执行了UPDATE语句，请求会被发到从库然后报错，而不是自动转到主库。
如何安装和配置MySQL Router
MySQL Router可以通过官方的rpm、deb包安装，也可以用二进制包直接解压使用。以Linux环境为例，安装完成后使用mysqlrouter_bootstrap命令进行引导式初始化，它会读取InnoDB Cluster的元数据，自动生成配置文件。
mysqlrouter --bootstrap root@主节点IP:3306 \ --directory /etc/mysqlrouter \ --conf-use-sockets=0 \ --user=mysqlrouter
引导成功后，配置文件mysqlrouter.conf的核心内容大致如下：
[DEFAULT] logging_folder = /var/log/mysqlrouter/ runtime_folder = /var/run/mysqlrouter/ config_folder = /etc/mysqlrouter/ [routing:primary] bind_address = 0.0.0.0 bind_port = 6446 destinations = metadata-cache://mycluster/?role=PRIMARY routing_strategy = first-available protocol = classic [routing:secondary] bind_address = 0.0.0.0 bind_port = 6447 destinations = metadata-cache://mycluster/?role=SECONDARY routing_strategy = round-robin-with-fallback protocol = classic
这里的关键点是destinations参数使用了metadata-cache协议，Router会持续查询集群的元数据，实时感知拓扑变化。如果主库宕机触发切换，Router拿到新的拓扑信息后，会把6446端口的新连接指向新的主库。routing_strategy参数决定路由策略，first-available表示始终选列表中第一个可用节点，适合主库路由；round-robin-with-fallback表示在多个从库间轮询，从库全挂了则回退到主库。
启动Router可以用systemd管理，也可以直接运行。生产环境建议在每个应用服务器本地部署一个Router实例，形成轻量级的Sidecar模式，这样即使某一台机器上的Router挂了，也不会影响其他应用节点，同时避免了Router自身成为单点。
MySQL Router与MySQL Proxy及连接池的对比
MySQL Proxy是MySQL很早以前推出的一个Lua脚本驱动的代理工具，可以拦截并改写SQL语句，功能上更灵活，但官方早已停止维护，稳定性差，不建议在新项目中使用。MySQL Router则完全不同，它不解析SQL、不支持改写语句，只做纯粹的连接转发和故障切换，换来的是极低的延迟和几乎可以忽略的资源占用。如果你需要的是读写分离加高可用，Router是更合适的官方方案。
和应用层的连接池相比，两者解决的是不同层面的问题。连接池管理的是连接的复用和数量控制，而Router管理的是连接的去向。比如Java应用中的Druid或HikariCP负责减少建连开销，但主库挂了之后连接池里的连接全部失效，应用仍会报错；Router则可以在主库切换后把请求导向新主库，两者通常是配合使用的关系。
使用中的注意事项与常见问题
第一个常见坑是已建立连接的切换问题。Router的故障切换只对新连接生效，如果一个长连接在主库宕机前已经建立，切换发生后这个连接会直接断掉，应用需要捕获连接错误并重连。所以使用Router的应用最好配置连接失败自动重试机制，并且在业务代码中容忍偶发的连接中断。
第二个问题是健康检查参数的调优。配置中有client_connect_timeout和server_connect_timeout等参数，控制连接超时时间。如果设置过长，故障切换时会感觉应用卡住；设置过短，网络抖动又容易导致误判。一般建议连接超时设置在3到5秒，并配合重试机制使用。
第三个问题是要不要单独部署Router机器。小规模场景下Router可以和应用部署在同一台服务器，减少一跳网络转发；规模较大时可以集中部署两到三台Router，前面再挂负载均衡。无论哪种方式，都要保证Router的数量不止一个，否则Router本身就成了新的单点故障，整个高可用架构就失去意义了。掌握这些要点后，MySQL Router就能在你的InnoDB Cluster架构中稳定发挥它应有的作用。
MySQL RouterMySQL路由MySQL InnoDB Cluster修改时间：2026-09-10 03:46:29