我还将添加一些关于 Power BI 的内容。
通常在 Power BI 模型中，您将使用“导入数据”模式。在这种情况下，当您更新源数据中的几行时，Power BI 存储引擎将创建所有源数据的全新完整副本（或者如果仅优化特定分区的过程）。Power BI 使用与不可更新列存储索引相同的引擎，因此每次更改后都需要重建整个索引分区。
您可以在此处阅读有关 Power BI 刷新的更多信息：https ://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data 。
通常您不会使用小于 1 天的分区，因此预计 15 分钟或 24 小时刷新会导致相同分区的重建，而 ETL 的这一阶段将花费相似的时间。
当然，这只是 ETL 过程的阶段之一，但通常是最长的一个。
Transform和Load的抽象概念没有什么具体可量化的，只有它们的具体实现是可测量的。为了能够对您的案例发表评论，我们需要具体了解您的转换和加载过程实际上在做什么。显然，某些转换可能需要比其他转换更长的时间。
但一般来说，正在处理的数据量肯定会影响ETL流程的整体运行时间。如果 24 小时时间范围和 15 分钟时间范围之间的数据量存在显着差异，但您的ETL流程在两种情况下的平均运行时间大致相同，那么肯定有问题，这是不正常的。
即使在这两种情况下都发生了索引扫描，如果数据量存在显着差异，总运行时间肯定会反映出来。索引扫描的运行时间是线性的（一般来说），基于索引中的行数。
我还将添加一些关于 Power BI 的内容。
通常在 Power BI 模型中，您将使用“导入数据”模式。在这种情况下，当您更新源数据中的几行时，Power BI 存储引擎将创建所有源数据的全新完整副本（或者如果仅优化特定分区的过程）。Power BI 使用与不可更新列存储索引相同的引擎，因此每次更改后都需要重建整个索引分区。
您可以在此处阅读有关 Power BI 刷新的更多信息：https ://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data 。
通常您不会使用小于 1 天的分区，因此预计 15 分钟或 24 小时刷新会导致相同分区的重建，而 ETL 的这一阶段将花费相似的时间。
当然，这只是 ETL 过程的阶段之一，但通常是最长的一个。
JD 和 Piotr 的答案很有用，并且包含有价值的数据，但不幸的是不是这个问题的真正答案。那不是他们的错。
当我开始深入研究时，我发现这只是一个 SSIS 包提取问题。当时我没有足够的知识深入研究 SSIS 集成报告仪表板以了解我所看到的内容。
我需要采取的最后一步是在 Visual Studio 中打开项目并看到 SSIS 工具箱设计器显示了多个步骤。学习这个过程是如何工作的。非常有趣和强大！
我终于到达了一个被完全提取（提取）的表，因为它缺少时间戳列。该表包含 3 个小列的 400 万行，SSIS 逻辑使用“查找”操作来决定是否需要更新或插入报表数据库。
此 SSIS 工具箱查找操作禁用了内存缓存选项！哎呀！
无论原始提取设置为多少分钟，每次处理此表都需要 40 分钟。
Power BI 与此无关。我为混乱道歉。