我有一个非常大的表 IMO（约 1.37 亿行），其中包含大量重复数据、大量NULL列等。
我正在考虑使用一个带有 a 的表来探索这个COLUMNSTORE INDEX，我IDENTITY在原始表中有一个列，这是我唯一的每一行都是唯一的列。
我应该忽略此列还是包含它？我已经读到您想将表的所有行都包含在 中，COLUMNSTORE INDEX但我也读到最佳候选者是具有许多非唯一行的列。
这只是一个糟糕的候选人COLUMNSTORE INDEX吗？
我使用的是 SQL Server 2012，所以它是一个非聚集列存储。我只是在探索可能的更好的方法来存储这些数据。更新是不存在的，尽管会通过 ELT 过程定期添加新行，所以我假设会在那里完成一些工作。有些人挖掘这些数据并生成大量报告，大量扫描行，有时会使服务器爬行，这迫使我们每天将副本卸载到辅助服务器。
我被要求清理表格的几列中的前面和后面的空格。该表是从平面文件导入的，并且有许多输入错误的行。
该表有超过 1.5 亿行。
到目前为止，我已经尝试执行一个更新语句来更新列ltrim(rtrim(columnname))，我还尝试创建一个临时表（堆）并insert into ... select from使用相同的ltrim(rtrim(columnname))语法。
在每种情况下，事务日志都会失去控制，直至耗尽磁盘空间。
我了解事务日志如何工作得相当好。然而，在执行这样的批量维护的情况下，我被难住了。
目前数据库处于大容量日志恢复模式，我每 30 秒运行一次事务日志备份，事务日志的增长速度继续超过我可以备份的速度。我已经研究过如何将这项工作分成批次，但似乎无法制定可以有效执行此操作的查询。我有一个可以关闭的身份字段，所有其他列都是varchar列。现在我认为答案是简单地为服务器获得更多磁盘空间，但是我希望有更好的解决方案。
我使用的是 Microsoft SQL Server 2014 企业版。
平面文件早已不复存在；这是一个在 10 年和 SQL Server 的许多版本中不断增长的表。只执行较小的增量批量更新，我相信新插入在插入之前已经被清理。所以我正在修理旧东西:(