不能。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 示例）
不是所有项目都能上中间件，小团队常选择在代码里维护从库列表并轮询。看似简单，实际容易漏掉状态感知和故障隔离。
比如 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，不是按实时延迟选最优
延迟感知这事没法偷懒，要么中间件配好规则，要么应用里多一次查询。漏掉这步，负载均衡就成了负优化。
