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