设置

在一个数据仓库中，我将一个事实表连接到20个维度。事实表具有3200万行和30列。这是一个临时暂存表，因此我不必与其他正在读取或写入该表的用户打交道。我从基础表中选择10列，并从各个维度中选择20列。尺寸表很小（介于3到15.000行之间）。连接的字段都是整数和nvarchars。我使用SELECT ... INTO语句。表上没有索引。

该查询的执行速度太慢，无法使用。

尝试过的解决方案

因为查询处理时间太长，所以我尝试了以下解决方案：

1. 将20个联接拆分为5个表上的4个联接。但是查询性能仍然很低。
2. 将索引放在外键列上。没有明显的时间减少。
3. 确保联接条件的字段为整数。我注意到性能提高了25％。不完全是我要寻找的。
4. 使用insert into语句代替select into。尽管数据库处于简单恢复模式，但由于日志文件增长而导致性能更差。

这些发现使我包括了实际的执行计划，该计划表明89％的成本在表插入中。其他成本是对事实表进行8％的表扫描，对内部联接进行2％的哈希匹配。

问题

1. 缓慢插入表的可能原因是什么？
2. 没有执行计划，有哪些方法可以识别此瓶颈？
3. 我可以采取什么措施来减少表格插入的费用？

缓慢插入表的可能原因是什么？没有执行计划，有哪些方法可以识别此瓶颈？

阅读如何分析SQL Server性能，特别是有关分析单个查询执行等待时间的部分。

我可以采取什么措施来减少表格插入的费用？

那将主要取决于性能分析的结果。首先，请确保SELECT部分尽可能快。假设问题是单线程完全记录日志插入，则一些解决方案是：

• 使用分区开关将数据“移入”。到目前为止，这是最好的解决方案。在单独的登台表中准备登台数据，然后将此登台表切换到DW表中。利用分区交换高效读取传输数据。

• 确保最小记录了INSERT。读取可以最小记录的操作以及最小记录的前提条件。即使您使用分区切换操作，仍然值得确保最小化登台表的构建。

• 确保您的IO子系统能够驱动快速负载。阅读介绍SSD。

以下是我的经验，可能会对其他人有所帮助。

我们试图将一些数据从一个数据库传输到另一个数据库，同时也进行了一些转换。测试转换我们做了很多插入操作，先修复了问题，然后删除，以便再次测试插入操作。但是，在进行一些插入和截断之后，我们的查询开始运行缓慢，而一个简单的插入开始花费长达9分钟的时间，而之前它运行了大约3分钟。

1. 好吧，我们首先开始考虑优化SELECT。我们使用#tempTables代替子查询。尽管这样做确实加快了速度，但仍然不令人满意。
2. 造成所有差异的原因是，在目标数据库上重建了索引并更新了统计信息，这使插入操作花费了大约2分钟的时间。

因此，请尝试这两种策略，看看如何为您解决问题。