为何Laravel/Doctrine原生数据库查询与MySQL CLI执行效果不同？

这问题我之前排查过好几次，核心原因其实是MySQL CLI和Laravel的数据库执行环境、上下文完全不一样，哪怕是同一条SQL语句，在两个环境里的执行逻辑也会有差异。下面拆解几个最常见的诱因：

1. 连接配置的差异 #

你在MySQL CLI里用的连接参数（比如默认字符集、collation、sql_mode），和Laravel在config/database.php里配置的可能完全不同：

• 比如Laravel默认会把数据库连接的字符集设为utf8mb4，而你的CLI可能用的是旧版的utf8（注意MySQL里的utf8其实是utf8mb3）。这时候你语句里指定的utf8_unicode_ci和Laravel连接的utf8mb4字符集不兼容，就会报错。
• 再比如sql_mode：Laravel默认可能开启了严格模式（比如ONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES），而你的CLI sql_mode可能更宽松，一些在CLI里能通过的语句，在严格模式下会触发警告或失败。

2. 事务的影响 #

Laravel的迁移默认是包裹在事务里执行的（除非你手动关闭），但MySQL的DDL操作（比如ALTER TABLE）在事务里的行为很特殊：

• 旧版本的MySQL（比如5.7之前）里，InnoDB的DDL操作会隐式提交事务，这会导致迁移里的其他操作被意外提交，或者触发事务相关的错误。
• 哪怕是新版本MySQL，Laravel的事务包裹逻辑也可能和直接在CLI执行（自动提交模式）的流程不一样，导致ALTER语句执行失败。

3. 权限与用户差异 #

别忽略最基础的点：你在CLI用的MySQL用户，和Laravel配置文件里的DB_USER是不是同一个？

• 如果Laravel的数据库用户没有ALTER TABLE的权限，那执行语句肯定会失败，但CLI用户有这个权限，自然能正常执行。这种情况查一下两个用户的权限就能发现。

4. PDO底层的细微处理 #

虽然DB::unprepared()是用来执行原生未预处理的SQL，但Laravel用的PDO底层还是会对连接做一些默认设置：

• 比如PDO可能会自动设置一些连接属性，比如PDO::ATTR_EMULATE_PREPARES，这可能会影响SQL语句的解析逻辑，和直接在CLI执行的纯原生解析有差异。

怎么排查解决？ #

给你几个实用的排查步骤：

• 看Laravel日志：去storage/logs/laravel.log里找具体的错误信息，这是最快定位问题的方式——比如是字符集冲突、权限不足还是事务报错，日志里会明确告诉你。
• 对比连接参数：在CLI执行SELECT @@sql_mode, @@character_set_connection, @@collation_connection;，然后在Laravel的迁移里加一行dd(DB::select('SELECT @@sql_mode, @@character_set_connection, @@collation_connection;'));，对比两者的参数差异，调整Laravel的配置适配语句。
• 关闭迁移事务：在你的迁移类里添加public $transactions = false;，或者用Schema::disableForeignKeyConstraints()配合执行ALTER语句，避免事务对DDL的影响。
• 调整语句适配Laravel配置：比如如果Laravel用的是utf8mb4，把语句里的utf8_unicode_ci改成utf8mb4_unicode_ci，保持字符集一致。

内容的提问来源于stack exchange，提问作者Noel De Martin