phpMyAdmin无法测试Laravel读写分离路由逻辑，因其仅是MySQL客户端，不参与PHP层的连接分发决策；Laravel的读写分离由Connection类在DB查询时动态路由，需通过日志、DB::connection()->getPdo()或Tinker验证实际连接目标。
phpMyAdmin里根本测不了Laravel的读写分离路由逻辑
phpMyAdmin 是个纯前端 MySQL 客户端，它只管连上某个 host + port + 用户，然后发 SQL。Laravel 的读写分离是 PHP 层做的连接分发——DB::table('users')->get() 走从库、DB::table('users')->insert(...) 走主库，这个决策发生在 Laravel 的 Connection 类里，phpMyAdmin 完全不参与也不感知。
你用 phpMyAdmin 登录 slave_user，只能验证“这个用户能不能连上从库”“有没有 SELECT 权限”，但无法模拟 Laravel 的读写意图识别、sticky 标记传递、事务内强制主库等行为。
- 你看到“查询成功”，不代表 Laravel 里
User::all()就真走到了这台从库 - 你手动执行
INSERT报错，也不代表 Laravel 写操作失败——因为 Laravel 写时压根不会用slave_user - phpMyAdmin 没有“请求生命周期”概念，所以
sticky => true在这里完全无效
真正该测的是数据库用户的最小权限和网络可达性
虽然测不了路由逻辑，但可以用 phpMyAdmin 快速确认两件事：从库用户有没有被锁死、主库用户是不是被误配成只读。
- 用
slave_user登录 phpMyAdmin，执行SELECT VERSION(), USER();—— 确认连的是预期的从库 IP，且没被GRANT错（比如误给了INSERT权限） - 用
master_user登录，执行INSERT INTO test_table (id) VALUES (1);+SELECT * FROM test_table;—— 确认主库用户可读可写，且没被read_only=ON卡住 - 在从库上执行
SHOW SLAVE STATUS\G（如果能进命令行更好），看Seconds_Behind_Master是否稳定在个位数；phpMyAdmin 里查不到这个，但延迟高了，sticky => false时必现脏读
验证 Laravel 实际路由走向，得用日志或 DB::connection()->getPdo()
想确认某条 Model::find() 到底连了哪台机器？不能靠 phpMyAdmin，得让 Laravel 自己说话。
立即学习“PHP免费学习笔记（深入）”；
- 临时在
AppServiceProvider::boot()里加：DB::listen(function ($query) { \Log::info('SQL on: ' . $query->connection->getPdo()->getAttribute(\PDO::ATTR_CONNECTION_STATUS)); });—— 日志里会打出类似mysql:host=192.168.1.10的实际 host - 更直接：在 Tinker 里跑
DB::connection('mysql')->getPdo()->getAttribute(\PDO::ATTR_CONNECTION_STATUS)，看返回的 host 是主还是从 - 注意：
sticky开关会影响结果。刚执行过save()，再查getPdo()就一定返回主库连接，哪怕你调的是get()
最容易被忽略的坑：.env 和 config/database.php 的字段冲突
很多人改完 config/database.php 以为万事大吉，结果发现从库流量为 0。大概率是 .env 里还留着 DB_HOST=xxx，而配置里又写了外层 'host' => env('DB_HOST') —— 这个顶层 host 会覆盖掉 read/write 子数组，导致 Laravel 直接忽略读写分离结构。
- 检查
config/database.php中'mysql'连接块：所有共用字段（database、username、password、charset）必须在外层，read和write里只放差异项（主要是host，可能还有port或weight） - 删掉外层的
'host' => env('DB_HOST')，否则read数组形同虚设 - 运行
php artisan config:clear后再测，缓存不清理，改了也白改
