Teradata删除所有vs DROP+；创造

我最近被分配到一个使用Teradata的项目中。 我被告知要严格使用DROP+CREATE而不是DELETE ALL，因为后者“以某种方式留下一些分配的空间”。这对我来说是违反直觉的，我认为这可能是错误的。我在网上搜索这两种方法的比较，但什么也没找到。 这只会强化我的信念，即删除所有内容不会受到上述问题的影响。 然而，如果是这样的话，我必须证明它（从实践和理论上）

所以，我的问题是：这两种方法在空间分配上有区别吗？如果没有，是否有官方文件（用户指南、技术规范等）证明

---

谢谢大家!

这里有一个讨论：关于同一个主题（尽管它并没有真正回答“以某种方式分配一些空间”部分）。他们实际上建议删除所有，但出于其他（性能）原因：

为了防止链接失效，我将引用：

“全部删除”会更快一些，尽管在实际操作中，它们的性能通常没有太大差异

但是，特别是对于定期运行的流程（例如每日批处理流程），我建议使用“全部删除”方法。这将减少工作量，因为它只删除数据并保留定义。请记住，如果删除定义，则需要访问多个字典表，当然，在重新创建对象时，必须访问这些表（通常）

除了性能方面，drop/create方法的缺点是，每次创建对象时，Teradata都会将“默认行”插入AccessRights表，即使对对象的后续访问是通过角色安全性和/或数据库级安全性控制的。您可能很清楚，AccessRights表很容易变大，并且非常倾斜。根据我的经验，许多站点都有一个定期清理此表的过程，删除冗余行。如果您的（通常是批处理）进程定期删除/创建对象，那么您只需向表中添加以前由干净进程删除的行，将来将由同一进程删除。对我来说，这一切听起来完全是浪费时间

---

您的印象是正确的，您在任何地方都没有找到任何关于“删除已分配的空间”的引用，因为这完全是错误的：-）

---

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

首先，您不能在Teradata中的一个事务中执行DROP/CREATE（在Oracle中，日常DDL还有其他问题）因此，当ETL流程变得复杂时，您可能最终会依赖于更重要的业务流程，而依赖于不太重要的业务流程（就像您可能会看到客户表为空的仅仅因为利率没有刷新 或者您在一个小列中有一个超过varchar值的）

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

---

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

DBC中报告的空间是否可能是表头？如果在不填充新表的情况下进行拖放和创建，则该空间将存在。