Knex迁移异常原因咨询：多Schema环境下迁移影响不符预期

嗨，这个问题我之前在项目里也碰到过类似的情况，PostgreSQL迁移时出现这种“跑偏到public schema”的情况，通常和以下几个核心因素有关，咱们逐个排查：

• 迁移脚本未明确指定目标Schema
  很多时候问题出在脚本本身：如果第一次迁移时你明确写了ALTER TABLE A.目标表 ADD COLUMN ...，而第二次脚本只写了ALTER TABLE 目标表 ADD COLUMN ...，PostgreSQL就会根据当前连接的search_path去查找表。要是search_path里public排在前面，且public下刚好有同名表，就会误操作public里的表；如果没有同名表，甚至可能直接在public创建新表（不过你的情况是修改字段，所以大概率是public下有同名表）。

• 数据库连接的search_path配置不一致
  PostgreSQL的search_path决定了默认Schema的搜索顺序。两次迁移如果使用的连接配置不同——比如第一次连接时设置了search_path = "A, public"，第二次连接的search_path变成了"public, A"——那脚本里未指定Schema的操作就会优先匹配public下的对象。你可以在迁移时执行SHOW search_path;来确认当前连接的搜索路径是否一致。

• 迁移脚本中的Schema切换遗漏
  如果你在第一次迁移脚本开头手动设置了SET search_path TO A;来切换到目标Schema，但第二次脚本里忘了添加这行命令，或者脚本执行时上下文被重置，就会默认回到search_path的初始配置（通常包含public）。这种情况在手动编写迁移脚本时很容易忽略。

• 迁移工具的默认Schema配置差异
  如果你用的是Flyway、Liquibase这类自动化迁移工具，它们通常有默认Schema的配置项。比如Flyway的defaultSchema参数，要是第一次迁移时配置了defaultSchema=A，第二次迁移时没设置或者改成了public，工具就会自动把未指定Schema的操作指向public。

• 数据库用户的权限与默认Schema设置
  每个PostgreSQL用户都有一个default_schema属性，如果两次迁移使用的数据库用户不同，其中一个用户的默认Schema是public，那未指定Schema的操作就会落到public。另外，如果用户对A Schema没有足够的操作权限，也可能出现 fallback到public的情况（不过这种情况一般会抛出权限错误，除非public下有可操作的同名表）。

建议你先从迁移脚本内容和连接的search_path配置这两点入手排查，这是最常见的问题根源。

内容的提问来源于stack exchange，提问作者nightmaredevil2010