Laravel怎么配置多个数据库_Laravel多连接数据库设置【说明】

在 Lara vel 中配置与使用多个数据库连接的完整指南

为应用引入第二个数据库连接，听起来只是改改配置，但实际操作时，不少开发者会踩进几个典型的“坑”里。下面就把配置要点和常见问题的解法，一次性说清楚。

config/database.php 里怎么加第二个 MySQL 连接

方法其实很直接：在配置文件里的 connections 数组中，把现有的 mysql 配置完整复制一份，然后改个名字，比如 mysql_analytics。这里真正的关键，往往不在于“添加”这个动作本身，而在于后续的环境变量映射和连接名的一致性，一个疏忽就可能导致连接失败。

• 必须同步更新 .env 文件：记得在 .env 中新增对应的环境变量，例如 DB_ANALYTICS_HOST、DB_ANALYTICS_DATABASE 等。如果漏了这一步，运行时要么会回退到默认值，要么直接抛出 Undefined index: host 这类错误。
• 连接名要规范：你定义的连接名（如 mysql_analytics）需要全小写，并且避免使用下划线以外的特殊符号。因为 Lara vel 在内部会把它当作数组键名来查找配置，拼写错误自然就找不到。
• 别动原配置：切忌直接修改原有的 mysql 配置项。尤其是在多环境共用的配置下，这很容易意外覆盖主数据库的设置，埋下隐患。

DB::connection('xxx') 调用时报 Class 'xxx' not found

遇到这个错误先别慌，这通常不是数据库配置错了，而是 Lara vel 错误地把你传入的字符串当成了一个类名去尝试自动加载。这说明调用方式可能用错了地方。

• 认清生效范围：通过字符串指定连接名，只在特定的几个地方有效，比如 DB::connection('mysql_analytics')->table(...)、Schema::connection() 或者在模型中定义 $connection 属性。在其他地方（比如某些依赖注入或手动实例化的场景）直接传字符串是没用的。
• 检查拼写一致性：如果在模型里设置了 protected $connection = 'mysql_analytics';，务必确认这个字符串和 config/database.php 里定义的键名完全一致，一个字母都不能差。
• 清除配置缓存：修改配置后，记得运行 php artisan config:clear。配置缓存没清掉的话，新添加的连接名是读取不到的。

事务跨连接不生效，A 库提交了 B 库回滚了

这是一个经典的误区。Lara vel 提供的 DB::transaction() 方法，其事务范围仅限于“当前”数据库连接，默认就是配置里指定的 default 连接。本质上，跨数据库的分布式事务并不被 Lara vel 原生支持——毕竟 MySQL 自身在不使用 XA 协议的情况下也不支持，而 Lara vel 并没有封装这一复杂机制。

• 避免错误写法：不要想当然地写出 DB::transaction(function () { DB::connection('a')->...; DB::connection('b')->...; }); 这样的代码，第二个连接的操作根本不会受到这个事务块的控制。
• 手动控制方案：如果业务上必须追求强一致性，那就需要自己动手，分别对两个连接使用 beginTransaction()、commit() 和 rollback()，并且要做好异常捕获和状态同步，复杂度会显著上升。
• 考虑最终一致性：对于大多数场景，更务实的做法是采用最终一致性方案。例如，先将数据写入主业务库，然后通过消息队列异步写入分析库，并配套完善的重试与补偿机制。

模型切换连接后，迁移命令不认新库

另一个常见困惑是：明明在模型里指定了 $connection = 'mysql_analytics'，但运行 php artisan migrate 时，迁移文件却跑到了默认库里去。这是因为迁移命令和模型的连接设置是两套独立的机制。

• 迁移需指定连接：迁移命令必须显式地通过 --database 参数来指定目标连接，例如：php artisan migrate --database=mysql_analytics。
• 迁移文件无需改动：好消息是，迁移文件本身的代码（如 Schema::create()）不需要做任何修改，Lara vel 会根据命令行参数自动将操作路由到正确的数据库。
• 状态查询也要带参数：同样，检查迁移状态时也要带上连接参数：php artisan migrate:status --database=mysql_analytics。否则，你看到的只是默认库的状态，容易产生误判。

说到底，配置多连接本身并不复杂，真正的挑战在于后续的维护。从查询构造器、模型、到数据库迁移、队列任务，甚至第三方包中可能的 DB:: 调用，每一个依赖数据库连接的地方，都需要仔细确认是否指向了正确的连接。只要漏掉一处，数据就可能被写入错误的库中，这才是最需要警惕的地方。