好，咱们今天聊聊 Laravel 的多数据库配置。说实话，我第一次接触这个功能时，心里挺忐忑，觉得肯定得折腾一大圈。但后来发现，Laravel 在数据库这块设计得很聪明，它把多数据库配置拆解得特别清晰，你只要按规矩来，基本不会出大岔子。比如说，你手头有个项目，一个库存放用户信息，另一个库管着订单数据，甚至还有个库专门做日志分析，这种场景在实际开发中很常见。Laravel 让你在配置文件里把每个数据库的链接信息写好，然后代码里随时切换，就像换频道一样简单。我第一次尝试时，就感觉这框架没白学，省了不少死磕底层代码的力气。
先说最基础的东西，就是配置文件。Laravel 的多数据库配置都集中在 里。打开一看，默认有个 连接，那是给主库准备的。要加第二个库，别在原来的数组里乱改，直接新增一个数组项，比如叫 。每个连接都要把 这些字段写清楚，别偷懒。我见过有人图省事，把两个库的配置混在一起写，结果查询时数据串了，找半天才发现是配置没分清。每个连接就像独立的身份证，给它取个名字，它就知道该连哪个库。另外， 这个字段也别忘了，有些项目表名带前缀，设对了能省去后面手动拼接的麻烦。如果你使用不同的数据库类型，比如一个 MySQL 一个 PostgreSQL，只需在配置里分别指定 为 和 ，Laravel 会自动处理语法差异。
配置写好之后，怎么用呢？这里有个核心概念叫“连接”。平时使用 ，Laravel 默认走的是 连接。但想查询另一个库的数据，就得显式告诉它换条路。比如 。就这么简单，把连接名字传进去，它就去对应的数据库里操作。我在业务里经常在同一个控制器里同时操作两个库：从主库取用户信息，从订单库查最近订单。这种场景下， 方法就像遥控器，按哪个按钮，电视就切到哪个频道。不过要注意，如果频繁切换连接，需确保每个连接的性能配置合理，比如连接池大小、超时时间，否则高并发时容易卡住。
再进阶一点，你可以在模型里指定默认连接。比如有个 模型，它对应的数据在订单库里，只需在模型类里加一行 。这样使用 时，Laravel 会自动去订单库查询，不用每次手动写 。这个设计特别适合数据逻辑清晰的场景。我遇到过一个项目，用户表和订单表分布在两个库，但模型关系仍需维护。比如一个用户有多个订单， 模型里定义 关系时，Laravel 默认去主库查关联表，需要在关系方法里指定正确的连接，否则会报表不存在的错误。解决办法是关系方法里加上 ，或者直接在 模型里固定连接，这样关联查询会自动使用子模型的连接。
多数据库配置还有个常见坑：事务处理。如果在同一个请求里要同时操作两个库，比如先往主库插入用户记录，再往订单库插入订单记录，订单库写入失败时，主库的数据就会变成脏数据。Laravel 的 默认只支持单个连接，跨库原子性需要手动控制。可以先开启两个数据库的事务：然后执行操作，全部成功就 ，只要有一次失败就两个都 。代码逻辑并不复杂，但要小心捕获异常，确保每个回滚都能执行。还有一种方案是使用分布式事务中间件，如 XA 协议或 TCC 模式，但这套东西比较重，小项目一般不必采用。
说到读写分离，Laravel 也能搞定。比如主库负责写，从库负责读，配置里可以写 和 两个数组。Laravel 会自动判断 SQL 类型： 走从库， 走主库。这个功能在高并发场景特别有用。我见过一个电商项目，订单表每天几百万条记录，写压力大，读操作更多，他们配置了一主两从，Laravel 的读写分离机制自动把查询分散到从库，主库专心处理写请求。不过要注意，从库的数据同步有延迟，插入后马上查询可能查不到。这时可以强制走主库读取，或使用 选项，让写操作后的一段时间内查询仍走主库，避免延迟问题。
聊点实战中的坑。多数据库配置最头疼的是迁移和填充。 默认只在主库执行迁移文件，如果想在订单库也创建表，需要在命令里指定连接：或者在迁移文件里手动调用 。我有个朋友，项目上线后才发现订单库的表没创建，就是因为迁移命令漏了参数。填充数据同理， 默认走主库，需要使用 选项或在代码里指定连接。还有一点，如果使用不同的数据库类型，比如 MySQL 和 SQLite，迁移文件里的数据类型定义可能不兼容。比如 MySQL 的 在 SQLite 里可能不支持，需要写通用语法或加条件判断。多数据库虽爽，但必须细心规划，别让灵活性变成维护噩梦。
