不能。MySQL主库本身不支持直连多个从库实现负载均衡，需依赖中间件（如ProxySQL）或应用层自行实现读请求分发，并注意从库延迟、健康检查与权重配置。

MySQL主库能直连多个从库做负载均衡吗

不能。MySQL服务端本身不提供客户端请求的读写分离或从库间负载均衡能力，mysql 命令行、JDBC、PDO 这些客户端连接的是单个地址，没有内置轮询或多从库路由逻辑。

常见错误现象：ERROR 1045 (28000): Access denied for user 或连接超时，往往是因为在应用里硬编码了多个从库地址却没做分发逻辑，结果只连了第一个或随机崩一个。

• 真正可行的路径只有两条：在中间件层（如 ProxySQL、MaxScale）做流量分发，或在应用层自己实现读请求的从库选择逻辑
• 别指望改 my.cnf 加几行就能让主库“自动推”读请求到从库——复制是单向的，不反向传查询
• 如果用 mysqlrouter，注意它默认只做故障转移，不开启 --conf-use-gr-notifications 和配置 ro-pool 就不会做读负载

ProxySQL 配置多从库读负载的关键参数

ProxySQL 是目前最轻量且可控的方案，但配置稍有偏差就读不到从库，或把写请求误发过去。

核心是三张表：mysql_servers 定义后端实例，mysql_replication_hostgroups 标明主从关系，mysql_query_rules 控制路由策略。

• hostgroup_id = 10 通常设为读组，hostgroup_id = 20 设为主组；必须在 mysql_replication_hostgroups 中配对 writer_hostgroup = 20 和 reader_hostgroup = 10，否则 ProxySQL 不会自动识别从库角色
• 从库权重通过 weight 字段控制，默认都是 1；想让某台从库承接 70% 读流量，就设 weight=7，另一台设 weight=3
• 务必关闭 mysql-monitor 的 monitor_enabled=0 再上线，否则它可能因延迟检测不准，把延迟稍高的从库直接踢出 mysql_servers

应用层手动轮询从库的坑（PHP/Python 示例）

不是所有项目都能上中间件，小团队常选择在代码里维护从库列表并轮询。看似简单，实际容易漏掉状态感知和故障隔离。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

比如 Python 用 pymysql 连接，如果只用 random.choice(servers)，遇到某台从库宕机就会抛 ConnectionRefusedError，整个读请求失败。

• 必须加连接预检：每次取从库地址前，先用 socket.create_connection((host, port), timeout=0.3) 快速探活
• 别用纯 round-robin，要带简单熔断：连续 3 次连接失败的从库，10 分钟内不再选它，这个状态得存在本地内存或 Redis 里，不能每次重置
• PHP 的 PDO 注意 PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION 要打开，否则连接失败静默吞掉，你根本不知道哪台从库挂了

从库延迟大时负载均衡反而加重问题

负载均衡不等于“平均分配”，把读请求均匀打到延迟 200ms 和延迟 2s 的从库上，用户感受到的是后者拖慢整体响应。

真实场景中，Seconds_Behind_Master 波动很常见，尤其在主库批量写入后。

• ProxySQL 可通过 mysql_server_read_only 和自定义监控脚本联动，把 Seconds_Behind_Master > 500 的从库临时移到另一个 hostgroup 并清空其 weight
• 应用层轮询时，别只看能否连通，还得查 SHOW SLAVE STATUS\G 的 Seconds_Behind_Master 字段——但要注意权限，REPLICATION CLIENT 权限必须授予连接用户
• 有些 ORM（如 Laravel 的 read_write_connection）默认不感知延迟，它只按配置列表顺序 fallback，不是按实时延迟选最优

延迟感知这事没法偷懒，要么中间件配好规则，要么应用里多一次查询。漏掉这步，负载均衡就成了负优化。