通过阅读ABAP官方文档，我想您知道它们之间的技术区别（标准是什么，排序是什么，哈希是什么）。

其余的只是成本问题。

1. 如果有索引，则更新表会降低性能。
2. 在没有足够索引的情况下，通过键读取表会降低性能。
3. 拥有索引会浪费内存。

通常，更多地考虑优化性能成本而不是内存成本。

基于此，请使用成本最低的解决方案：

• 如果您需要写入内部表而不读取它（或不通过键读取它），请使用标准表。
• 等等。

GáborMárián值得回答！

一些实用指南：

标准表：

• 当数据少于100行时，仅使用标准表，其他任何事情都是开销，除非您需要通过特定键从这些行中读取数千次 在程序执行期间
• ，当您有成千上万的数据行时，却从不读取它们（例如，将其转储为CSV或XLS），只需使用标准表即可。
< li>搜索和删除O（n）的最坏情况性能：需要查看所有n行（行中的"键"），以查找最坏情况下的搜索键（顺序搜索）
• 插入O（1）的性能：插入/添加新行而不必处理关键约束

排序表：

• 在需要时 表（始终）已排序，obvio 通常（您可以使用标准表并手动进行排序，但这是"更多"的编码，如果在程序执行期间必须重做则效率较低）
• （如果有） 数据； b）通常需要使用非唯一键（当然也可以是唯一的）从数据中读取数据；或者c）需要按索引访问数据
• 搜索/插入/删除操作的最差情况 （log n）：要查看log n键，在最坏的情况下（对数搜索）查找搜索到的键

哈希表：

• 如果您有a）大量数据，并且b）需要经常通过唯一键（不能是唯一的）读取数据，并且c）您不需要按索引访问它们
• 平均用例性能 for search/insert/delete O（1）：平均需要一次查找才能找到搜索到的密钥（哈希算法"查找"存储桶，理想情况下，存储桶中只有一个密钥）
• 最差 搜索/插入/删除O（n）的案例性能：需要使用所有n个键来查看哈希索引，才能找到 最坏情况下的搜索键（哈希算法"查找"存储桶，但大多是在存储桶本身中进行顺序搜索）

通常，在读取/插入/删除时，散列 表应该胜过排序表（就读/删除而言，标准表要比两者都要差得多），但是根据数据的不同，可能存在实例，其中排序胜过散列。 如果行数少于1万或什至100,000（并且读取访问的数量没有不成比例的数字），那么当用户等待执行结束时，您甚至可能不会注意到它们之间的差异（比较 到标准表，您会注意到它是用户）。

因此，这全都取决于您的要求，并且，如果需要，您需要仔细计划实现，并可能使用不同的表对大型测试数据进行性能测试 类型。 但是，如果您的测试数据与生产数据有很大不同，则您的测试可能是"无用的"。

@ GáborMárián谢谢，我通过上面的链接，清楚地理解了两者之间的区别。

从健壮的编程角度（应该始终在性能考虑之前）， 仅在确实需要时（例如CL_SALV_TABLE），才使用HASHED表作为首选项，然后使用SORTED表和STANDARD表。

在20年中，我从未遇到过 性能或内存 遵循此指南的问题。

@ GáborMárián感谢您提供此链接。 完美答案。 我要关闭此线程。

仅当您拥有用于所有频繁访问的完整键来访问它时，散列表才可以具有更好的性能。（ 或有辅助键来支持其余的键）。 此外，哈希表仅带有唯一键和 no 不允许索引访问（通过主键）。 通常，这是确定是否可以使用它们的因素。

内存消耗也有不同的成本。

最重要的是：标准表不应用于频繁查找键的大量数据。 即使对它们进行了排序，也只有READ TABLE BINARY SEARCH可以利用该顺序（没有手动编码技巧就不能进行LOOP/MODIFY/DELETE）。
对于具有大量数据（ 最典型的情况是，当您仅追加行时，最后一次遍历整个表，仅此而已）–开发人员需要知道自己在特殊情况下的工作