我无法控制的一个过程是每晚在 MySQL 数据库中删除和重新创建表。如果它每次都以相同的方式重新创建表，这将不是问题（我认为）。但事实并非如此：每天早上我进来打开我的 SSIS 项目，然后我在随机表/列中收到新的元数据验证错误/警告，因为这个通宵的过程正在创建varchar长度根据数据而变化的列，所以昨天我有一个长度为 90 的列，今天同一张表中的同一列现在有 208 的长度，明天可能是一个不同的故事......或不是。
这个 MySQL 数据库是我的主要数据源——我在 SQL Server 上有我的暂存数据库，并且通过链接服务器连接，我正在使用 SSIS 从这些表中选择数据并输入到 SQL Server 表中（添加了一些列），这在用远程数据填充它们之前，我正在截断它们（因此此登台数据库中的元数据是固定的）。
为什么 SSIS 需要验证外部元数据？如果我关闭设计时验证，它说它被延迟到运行时 - 这是否意味着我只会将问题从设计时推到运行时，并且仍然得到一个失败的包？
我有一个 T-SQL 脚本，可以执行从 MySQL 到 SQL Server 暂存表的数据传输，但该脚本运行大约 45 分钟，而 SSIS 包，当所有元数据都是最新的时，运行大约 5分钟 - 不用说，我更喜欢找到一种方法让 SSIS 停止抱怨过时的元数据，而不是使用该脚本。
有没有办法在 SSIS 中使用这种数据源的变形器并保持理智？
在那种不愉快的情况下，我认为最好的策略是将它与 SSIS 分开。要么将其移出到具有更改视图的链接服务器，要么使用其他一些 etl 工具（如 powershell 脚本）将其从跳舞模式中移出到具有固定模式的表中。如果您有任何历史记录，您应该能够为该字段的上限大小猜测一个合理的值。你总是可以把它变成 varchar(max)。我假设 MySql 正在执行“选择”以创建表。在任何情况下，MySql 都不会对数据做出任何可靠的断言，因此您需要在 SSIS 满意之前自己进行断言。