PHP应用中需手动区分读写操作以实现读写分离：用正则匹配SQL开头关键词判断类型，PDO/MySQLi应分设主从连接，ORM优先使用框架内置支持，事务内所有操作必须走主库。
PHP 应用里怎么识别读操作和写操作
读写分离的前提是代码里能明确区分哪些 SQL 是读（SELECT）、哪些是写（INSERT、UPDATE、DELETE、REPLACE、ALTER 等）。PHP 本身不自动判断，得靠你控制连接来源。
常见错误现象：所有请求都打到主库，从库完全没被用上；或者写操作误发到从库，直接报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 用 PDO 或 MySQLi 时，别复用同一个
$pdo实例做读写 —— 要准备至少两个连接：一个连主库（write_host），一个连从库（read_host） - 简单判断逻辑可封装成函数，比如
isWriteQuery($sql)，用preg_match匹配开头关键词（注意忽略注释和空格，^\s*(INSERT|UPDATE|DELETE|REPLACE|ALTER|CREATE|DROP|TRUNCATE)） - ORM 用户（如 Laravel Eloquent、ThinkPHP）优先走框架内置的读写分离支持，别自己手动切连接 —— 它们通常在
DB::table()->get()用从库，->save()或->update()自动切主库 - 事务内所有操作必须走主库，哪怕只有
SELECT—— 从库可能有延迟，导致读不到刚写入的数据
MySQL 主从同步配置的关键步骤和坑
PHP 层再怎么切连接，后端没真正主从同步起来，读写分离就是空谈。重点不在“配完”，而在“配稳”。
常见错误现象：从库 Seconds_Behind_Master 持续增长；重启后同步中断；字符集不一致导致中文乱码或同步失败。
立即学习“PHP免费学习笔记（深入）”；
- 主库必须开启
binlog_format = ROW（推荐），避免语句级复制（STATEMENT）在函数、临时表、非确定性语句下出错 - 主从
server_id必须不同，且不能为 0；从库启动前确保relay_log路径有写权限，否则报错Failed to initialize the master info structure - 首次同步建议用
mysqldump --single-transaction --master-data=2导出，还原后执行CHANGE MASTER TO ... MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy，别依赖SHOW MASTER STATUS当前值直接配，容易跳过部分 binlog - 从库加
read_only = 1（但 root 仍可写），并考虑加super_read_only = 1（MySQL 5.7+）防误操作；同时主库关掉skip_slave_start，避免重启后同步自动停止
PHP 连接池/中间件方案选型的实际考量
手写读写分离逻辑短期可行，但项目变大后维护成本高。要不要引入中间件？取决于团队能力和数据一致性要求。
常见错误现象：用 mysqlnd_ms 扩展但没关掉 mysqli.reconnect，导致故障转移后连接未重连；或用 MaxScale 但没配好健康检查，从库挂了还在转发查询。
-
mysqlnd_ms（PHP 原生扩展）轻量，适合小团队，但只支持 MySQL，且已多年无实质更新；启用后需在mysqlnd_ms.json里明确定义master和slaves，并用mysqli::query()触发路由，mysqli::real_query()会绕过 - Proxy 类方案（如
MaxScale、ProxySQL）更透明，PHP 完全无感，但多一层运维负担；ProxySQL的mysql_query_rules可按 SQL 模式匹配强制走主库（比如含FOR UPDATE的 SELECT） - Laravel 用户直接配
'read' => [...], 'write' => [...]在config/database.php即可，框架自动处理；ThinkPHP 6 需设'deploy' => 1并指定'master_num' => 1 - 不要迷信“自动故障转移”——从库宕机后，流量切到其他从库前，得确认延迟是否可控；主库宕机更麻烦，PHP 层无法自动升从库为主，得靠外部高可用工具（如 MHA、Orchestrator）或人工干预
延迟读（stale read）和强一致读怎么取舍
从库延迟不是 bug，是主从复制的固有特性。关键是你敢不敢读旧数据，以及用户能不能感知。
常见错误现象：订单支付成功后查不到新订单；后台审核页看到“待审核”状态，刷新变“已通过”，因为两次请求落到不同从库，延迟不一致。
- 对一致性要求高的场景（如用户中心、资金流水），写完立刻要读，必须走主库 —— 可在 DAO 层加标记，比如
getUser($id, $force_master = true) - 允许几秒延迟的场景（如文章列表、商品评论），放心走从库；但别假设“所有从库延迟一样”，用
SHOW SLAVE STATUS\G中的Seconds_Behind_Master做路由依据时，要加超时和兜底（比如延迟 > 5 秒就切主库） - MySQL 8.0.14+ 支持
SELECT ... FROM tbl READ CONSISTENT（需开启group_replication_consistency），但 PHP 驱动需确认是否透传该 hint；更通用做法是写完后 sleep(0.1)，再读从库（仅限低频、容忍毛刺的业务） - 缓存（Redis）其实是更好的“延迟缓冲层”：写主库 + 更新缓存，读先查缓存，不存在跨库延迟问题；但要注意缓存击穿和双删时机
主从延迟不是配置调优能彻底解决的，它由网络、磁盘 IO、大事务、从库负载共同决定。比起压榨同步速度，更实际的是在应用层划清“可延迟”和“不可延迟”的边界 —— 这块最容易被忽略，也最影响上线后的稳定性。
