我最近被分配了一个使用 Teradata 的项目。我被告知要严格使用 DROP+CREATE 而不是 DELETE ALL，因为后者“以某种方式分配了一些空间”。这对我来说是违反直觉的，我认为这可能是错误的。我在网上搜索了两种方法之间的比较，但我一无所获。这只会加强我的信念，即 DELETE ALL 不会受到上述问题的影响。但是，如果是这样的话，我必须证明它（无论是在实践上还是理论上）。
所以，我的问题是：这两种方法的空间分配有区别吗？如果没有，是否有官方文件（用户指南、技术规范等）可以证明这一点？
谢谢！
这里有一个讨论：http: //teradataforum.com/teradata/20120403_105705.htm关于同一主题（尽管它并没有真正回答“以某种方式分配一些空间”部分）。他们实际上建议DELETE ALL但出于其他（性能）原因：
我会引用以防链接失效：
“全部删除”会更快，尽管实用起来通常它们的性能并没有太大差异。
但是，特别是对于定期运行的流程（例如每日批处理流程），我建议使用“全部删除”方法。这将做更少的工作，因为它只删除数据并保留定义。请记住，如果您删除定义，那么这需要访问多个字典表，当然，当您重新创建对象时，您必须（通常）访问这些相同的表。
除了性能方面，删除/创建方法的缺点是每次创建对象时，Teradata 都会将“默认行”插入 AccessRights 表中，即使随后对对象的访问是通过角色安全性和/或数据库级别控制的安全。您可能很清楚，AccessRights 表很容易变大并且非常倾斜。根据我的经验，许多站点都有一个定期清理此表的过程，删除多余的行。如果您的（通常是批处理）进程定期删除/创建对象，那么您只是将行添加到表中，这些行以前已被干净的进程删除，并且将来会被同一进程删除。这对我来说听起来完全是浪费时间。
您的印象是正确的，您在任何地方都没有找到任何对“DELETE 留下一些分配空间”的引用，因为它完全是错误的 :-)
DELETE ALL 类似于其他 DBMS 中的 TRUNCATE，并且在大多数情况下使用快速路径处理：
首先，您不能在 Teradata 的一个事务中执行 DROP/CREATE（在 Oracle 中，日常 DDL 还存在其他问题），因此当 ETL 流程变得复杂时，您最终可能会依赖于更重要的业务流程依赖于不太重要的业务流程（例如您可能会看到客户表为空，只是因为未刷新利率或仅在一个小列中有超过 varchar 值）
我的意见：使用事务和模块化编程。在 Teradata 中，这意味着尽可能避免 DDL，并使用 DELETE/UPDATE/MERGE/INSERT 而不是 DROP/CREATE。
我们在 Postgres 中的情况略有不同，其中 DDL 语句是事务性的。