Sql server 表插入性能优化

Question

环境

在数据仓库中，我将一个事实表连接到 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. 我可以采取哪些措施来降低表插入的成本？

Answer 1

表插入慢的可能原因是什么？在没有执行计划的情况下，有什么方法可以识别这个瓶颈？

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

我可以采取哪些措施来降低表插入的成本？

这在很大程度上取决于性能分析的结果。首先，确保SELECT部分尽可能快。假设问题是单线程完全记录插入，一些解决方案是：

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

• 确保 INSERT 被最低限度地记录。阅读可以最少记录的操作和最少记录的先决条件。即使您使用分区切换操作，仍然值得确保临时表的构建最少记录。

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