mysql主从复制是数据库自身配置的异步复制机制，主库将数据变更写入binlog，从库通过i/o线程拉取并写入relay log，再由sql线程重放实现同步；phpenv仅提供多实例运行环境，不参与复制逻辑。
主从复制不是phpEnv配出来的，是MySQL自己配的
phpEnv只是个本地开发环境套件，它不参与、也不控制MySQL主从复制逻辑。所谓“phpEnv配置主从”，实际是用phpEnv启动了两个MySQL实例（比如一个跑在3306，一个跑在3307），然后你手动在这两个MySQL之间配主从。phpEnv本身没提供图形界面或命令一键开启主从。
常见错误现象：SHOW SLAVE STATUS\G 显示 Slave_IO_Running: No，或者报错 ERROR 2003 (HY000): Can't connect to MySQL server——大概率是phpEnv里两个MySQL没开远程访问，或者防火墙/端口没通，而不是phpEnv哪里要“设置”。
- 确认两个MySQL实例是否真的在运行：用
netstat -tuln | grep :330看端口（如3306、3307）是否监听 - 主库必须开启
log-bin，且server-id设为非零唯一值（如1） - 从库的
server-id必须和主库不同（如2），并加read-only = 1防误写 - 主库创建复制用户时，
'repl'@'%'中的%在phpEnv本地环境下可能不生效，建议改用'repl'@'127.0.0.1'或具体IP
PHP代码里不区分主从，读写分离就等于没做
即使MySQL主从跑起来了，PHP默认还是只连一个库。你得在代码里显式决定哪条SQL走主库、哪条走从库。框架如Laravel会自动处理，但原生PDO或自研DB类必须自己路由。
典型错误：所有 $pdo->query("SELECT ...") 都连着同一个 $pdo 实例，而这个实例指向的是主库——结果从库完全闲置，负载一点没降。
- 至少维护两个PDO连接：
$pdoMaster（写）和$pdoSlave（读），别复用 - 用正则判断SQL类型：
preg_match('/^\s*(SELECT|WITH|SHOW)/i', $sql)判读，其余一律走主库 - 事务中禁止切从库：
$pdoMaster->beginTransaction()后，所有SELECT也必须用$pdoMaster，否则可能读不到刚写的行 - 强一致性读要留接口，比如
db()->select()->useMaster()->from('users')->where('id', 123)->exec()
PDO连接参数差异直接影响从库是否可用
从库常设 read-only = 1，一旦你用root连上去执行 INSERT，直接报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。这不是PHP问题，是MySQL拒绝写入。但PDO默认行为会让这种错误中断整个流程。
所以从库连接要主动规避异常中断：
- 从库PDO构造时关掉异常模式：
PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT - 主库连接建议开异常：
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，写失败必须立刻暴露 - 禁用预处理模拟：
PDO::ATTR_EMULATE_PREPARES => false，避免从库不支持PREPARE时报错 - 持久连接名必须区分主从，例如DSN里写成
"mysql:host=127.0.0.1;port=3306;..."和"mysql:host=127.0.0.1;port=3307;..."，不能只靠host一样就复用
延迟和一致性是线上最常被忽略的点
主从延迟几秒很常见，但业务代码往往假设“写完立刻能读”。比如用户注册后跳转到个人页，SELECT * FROM users WHERE id = ? 在从库查不到刚插入的记录，页面就空白——这不是数据库没配好，是代码没兜住。
最容易被绕过的其实是锁语句：SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 必须走主库，否则锁根本不起作用，还可能引发死锁或数据不一致。
还有个隐形坑：某些ORM的 ->count()、->exists() 方法底层仍是 SELECT，但开发者默认以为“只是查个数，无所谓延迟”，结果统计不准。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
