thinkphp需直连maxscale而非后端mysql，配置hostname和hostport指向maxscale监听地址（如192.168.3.102:4006），关闭rw_separate；读写分离、因果读取（causal_reads=local）、sql过滤、监控账号权限等均须在maxscale侧配置，tp仅作普通mysql使用。
ThinkPHP 本身不解析 SQL 语句，也不会自动把 SELECT 转发到从库——哪怕你配了 rw_separate => true，只要后端不是真正的主从节点直连，而是走 MaxScale，那 TP 就只当它是个普通 MySQL 实例。所以想让 ThinkPHP 和 MaxScale 配合好，关键不在 TP 配置里写多少个 read，而在于让 MaxScale 成为唯一出口，且 TP 完全信任它。
ThinkPHP 连接地址必须指向 MaxScale 监听端口
MaxScale 启动后监听的是自己的端口（比如 4006），不是后端 MySQL 的 3306。TP 的数据库配置里 hostname 和 hostport 必须填 MaxScale 的 IP 和端口，而不是主库或从库地址。
- 错误写法：
'hostname' => '192.168.3.101'（直接连主库）或'hostname' => '192.168.3.100,192.168.3.101'（TP 自己做分发，绕过 MaxScale） - 正确写法：
'hostname' => '192.168.3.102', 'hostport' => 4006（指向部署 MaxScale 的机器） - TP 不需要开启
deploy或rw_separate，因为读写分离已由 MaxScale 在协议层完成，TP 只需当它是个“智能 MySQL”用 - 连接用户必须是 MaxScale 配置中
[service]段指定的user和passwd，不是后端 MySQL 的 root 用户
MaxScale 的 readwritesplit 路由必须启用 causal_reads
默认情况下，readwritesplit 可能将刚写入的数据查询路由到延迟较高的从库，导致 TP 页面查不到新记录（比如注册后跳转个人页空白）。启用因果读取（causal reads）可强制 MaxScale 等待从库追上主库位点，或超时后自动切回主库。
- 在
/etc/maxscale.cnf的[service]段添加：causal_reads=local和causal_reads_timeout=5（单位秒） - 该机制依赖 MySQL 的
gtid_executed或 binlog 位置，确保主从开启了 GTID 或至少启用了log_bin和server_id - 如果关闭
causal_reads，又没在 TP 业务逻辑里手动处理“写后立即读”，就会出现数据可见性问题，这不是 TP 的 bug，而是主从延迟的真实体现 -
max_slave_replication_lag=30这类参数仅作健康检查，不解决因果一致性；它只决定“是否把该从库踢出路由池”，不保证当前查询一定落到最新从库
SQL 过滤必须在 MaxScale 层配置，TP 无法干预
ThinkPHP 的模型钩子、DB 类中间件、或者自定义 filter 方法，都发生在 PHP 进程内，对已经发给 MaxScale 的 SQL 无效。真正起作用的过滤，只能在 MaxScale 的 filter 插件中定义。
- 例如屏蔽
DROP TABLE：在[service]段加filters=qlfilter，再定义[qlfilter]段启用match=^DROP\s+TABLE并设action=reject - TP 中用
Db::execute("DROP TABLE user_log")会直接被 MaxScale 拦截并返回错误Access denied; you need (at least one of) the DROP privilege(s) for this operation，和 MySQL 权限报错格式一致 - 别试图在 TP 的
app\common\behavior\DbQuery.php里做 SQL 替换——它拦不住预编译语句，也拦不住原生query()调用 - 敏感字段脱敏（如手机号）这类需求，不能靠 TP 模型
getMobileAttr处理，得用 MaxScale 的regexfilter插件在返回结果前重写字段值
监控账号权限不足会导致 MaxScale 启动失败或服务中断
MaxScale 启动时会用监控账号连接所有后端服务器，若权限缺失，[monitor] 模块会持续报错，readwritesplit 可能退化为只连主库（即读写全部打到 master），整个读写分离形同虚设。
- 主库上必须执行：
CREATE USER 'maxscale_monitor'@'192.168.3.%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'maxscale_monitor'@'192.168.3.%'; - 路由账号（用于读取
mysql.user）需额外授权：GRANT SELECT ON mysql.user TO 'maxscale_router'@'192.168.3.%'; GRANT SELECT ON mysql.db TO 'maxscale_router'@'192.168.3.%'; - 注意网段匹配：如果 MaxScale 部署在
192.168.3.102，但监控账号只允许'maxscale_monitor'@'localhost'，连接必然失败 - 用
maxadmin --user=admin --password=mariadb登录后执行list servers，看到状态不是Running而是Down，第一反应就该查监控账号权限和网络连通性
最易被忽略的一点：MaxScale 的 causal_reads 机制在事务中行为特殊——它只对单条非事务语句生效；如果 TP 开启了事务（Db::startTrans()），MaxScale 会把整个事务绑定到同一个后端节点（通常是主库），此时即使你写了 SELECT，也不会被分流到从库。这不是配置错误，是设计使然。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
