读写分离需外部组件路由，MySQL单实例不自动识别读写类型；必须通过中间件或应用层将SELECT定向从库、DML定向主库，并确保从库read_only=ON、合理调优参数、动态权重分配及事务内读写粘性控制。
读写分离不能自动生效，必须由外部组件路由
MySQL 单实例本身不识别 SELECT 或 INSERT 类型，也不会自动把读请求发到从库。所谓“分担压力”，本质是人为把 SELECT 请求定向到从库、INSERT/UPDATE/DELETE 定向到主库——这个逻辑必须靠中间件或应用层实现。
常见错误现象：SELECT 还是打到主库、从库连接池没启用、事务里混用读写导致数据不一致。
- ProxySQL、ShardingSphere-JDBC、MyCat 是主流选型；ProxySQL 对已上线系统侵入最小，但
mysql_servers表中weight没设会导致流量全打一台从库 - 应用层直连需手动管理多数据源，容易漏写
@Transactional(readOnly = true)或错配数据源 - 所有方案都依赖从库开启
read_only=ON，否则中间件无法识别其为只读节点
主从延迟直接影响读一致性，不能无条件甩读请求
从库同步是异步的，Seconds_Behind_Master 可能为几十秒甚至更长。用户刚下单就查订单，若走从库，大概率读不到最新状态。
真实业务中，不是所有 SELECT 都能容忍延迟。
- 支付成功后查订单、注册后查个人资料、后台审核后查状态——这类场景必须强制走主库
- ProxySQL 支持
/*+ FORCE_MASTER */注释，但需先开启mysql-query_rules.fast_forward，否则注释被忽略 - 监控
stats_mysql_connection_pool表比SHOW POOLS更准，能确认连接是否真分发到了从库
从库不是“复制完就能用”，配置不当反而拖慢整体性能
从库默认配置是照搬主库的，但读负载和写负载对参数敏感度完全不同。不做针对性调优，可能吞吐上不去，还放大延迟。
典型误配：从库仍开启 log_bin、保留 query_cache、innodb_buffer_pool_size 过小。
- 关闭
log_bin（设log_bin=OFF），避免冗余日志开销 - 禁用
query_cache（5.7+ 已废弃，但旧版本仍可能默认开启） -
innodb_buffer_pool_size应设为物理内存 70%~80%，专注缓存读热点 - 开启并行复制（
slave_parallel_workers > 0），尤其在多库多表写入时明显降低延迟
读库负载不均比没做读写分离更危险
简单轮询分配读请求，会把大量查询压到延迟高、CPU 弱的从库上，造成局部雪崩。健康检查失效时，故障从库还在持续收请求。
真实线上环境，权重必须动态可调。
- 按
Seconds_Behind_Master、CPU 使用率、心跳响应时间实时计算权重，而非静态配置 - 中间件必须支持自动剔除不可用从库（如 ProxySQL 的
mysql_server_connect_timeout和mysql_server_read_only_check_interval） - 低配从库适合跑报表类慢查询，高配从库承接核心接口读请求，规格差异化部署比“一视同仁”更有效
REPEATABLE READ 下极易出现幻读或不一致结果。 
