在做 SAP 项目时，性能问题往往不是出在数据库，也不是出在 CDS View 或者 OData 协议本身，而是出在最不起眼的一行代码：你选了哪一种 ABAP 内表。
很多人习惯性把结果集塞进一个STANDARD TABLE，随后在循环里READ TABLE ... WITH KEY做查找。开发机上几千条数据跑得飞起，一到真实业务量（几十万、上百万行）就开始抖动，SAT 里一看，时间全耗在内表查找上。更尴尬的是，这类问题在 SAP Gateway（SAP_GWFND）里特别常见：一次 ODataGET_ENTITYSET里既要组装返回结构，又要做权限、文本、状态、汇总等一堆查找；如果查找策略不对，服务响应时间会呈指数级恶化。
这篇文章用一段极短的可执行代码，把三种常用内表（标准表、排序表、哈希表）的插入与读取特性讲透，并给出在 Gateway、RAP、S/4HANA（public cloud / private cloud）场景里可直接落地的选型建议。
三种内表的底层行为：别只背概念，要理解代价
ABAP 里常用的三种内表类型是：
STANDARD TABLE：不保证按 key 排序，追加写入非常轻量；SORTED TABLE：按 key 始终保持有序，插入时系统会把行放到正确位置；HASHED TABLE：用哈希算法管理行，通过唯一 key 做快速定位。
SAP 的官方学习材料对它们的读取行为
