Teradata DELETE ALL与DROP+CREATE的区别

Question

我最近被分配到一个使用Teradata的项目。我被告知严格使用DROP+CREATE而不是DELETE ALL，因为后者“留下了一些空间”。这对我来说很反直觉，我认为这可能是错误的。我在网上搜索了两种方法的比较，但没有找到任何信息。这只加强了我认为DELETE ALL不会受到上述问题的影响的信念。然而，如果是这样的话，我必须证明它（从实践和理论上）。因此，我的问题是：这两种方法之间是否存在空间分配方面的差异？如果没有，是否有官方文件（用户指南、技术规范或其他）可以证明这一点？谢谢！

- agdev84

---

DBC.DiskSpace 报告的空间是否可能是表头？如果您在没有填充新表的情况下执行 DROP 和 CREATE，则会存在该空间。 - Rob Paller

Answer 1

这里有一个讨论：http://teradataforum.com/teradata/20120403_105705.htm，讨论了同样的问题（尽管它实际上并没有回答“保留某些空间分配”的部分）。他们实际上推荐使用DELETE ALL，但出于其他（性能）原因：

我引用一下以防链接失效：

“删除所有”将更快，虽然实际上它们之间的性能差异通常不大。

然而，特别是对于经常运行的流程（比如每日批处理），我推荐使用“删除所有”方法。这样做会少做一些工作，因为它仅仅移除数据，而保留定义。请记住，如果删除定义，则需要访问多个字典表，当然在重新创建对象时您还必须访问这些表（通常情况下）。

除了性能方面，删除/创建方法的缺点是每次创建对象时，Teradata都会向AccessRights表插入“默认行”，即使随后对该对象的访问是通过角色安全和/或数据库级别安全进行控制的。就像你可能知道的那样，AccessRights表很容易变得很大而且数据分布不均。根据我的经验，许多站点都会有一个定期清理该表的过程，以删除冗余行。如果您（通常批处理）的流程经常删除/创建对象，则只是将先前被清理过的行添加到表中，并在未来再次通过相同的过程删除。这对我来说听起来完全是浪费时间。

- Jcl

Answer 2

您的印象是正确的，您没有在任何地方找到“DELETE leaves some space allocated”的参考，因为它是错误的 :-)

DELETE ALL类似于其他DBMS中的TRUNCATE，在大多数情况下使用fastpath处理：

- dnoeth

Answer 3

首先，在 Teradata 中你不能在一个事务中执行 DROP/CREATE（在 Oracle 中每天的 DDL 也会有其他问题），所以当 ETL 过程变得复杂时，你可能会出现更重要的业务流程依赖于不太重要的流程（比如你可能会看到客户表为空，只是因为利率没有更新或者你只有一个小列中的值超过了 varchar 的限制）。

我的观点是：使用事务和模块化编程。在 Teradata 中，这意味着尽可能避免使用 DDL，并使用 DELETE/UPDATE/MERGE/INSERT 而不是 DROP/CREATE。

在 Postgres 中，我们有稍微不同的情况，DDL 语句是事务性的。

- Eugene Lycenok