我的理解是app引擎上的索引列表是通过复制列表的每个值的所有数据来存储的。因此，多个列表会创建笛卡尔产品类型爆炸，并且获取实体需要将所有这些“行”（最多5000个）收集到一个实体中，谷歌调用序列化开销，最好避免使用。我的理解是否正确？
如果这就是app引擎的工作方式，我想知道是否以相同的方式存储未索引的列表（需要相同的数据复制和相同的序列化开销），或者它们是否以二进制或其他方式存储，因为您永远不需要知道它们用于查询/检索的内容。
所以我想我要问的是：无索引列表是否有序列化开销和5000行限制？如果是这样，怎么可以避免这种情况。
由于
答案 0 :(得分：2)
你在这里混淆了两个不同的主题。索引和未索引的列表都作为序列化实体协议缓冲区的一部分存储，列表的每个元素分别存储。这里有空间开销，因为属性的名称与每个元素一起存储 - foo = [1,2,3]存储为[（foo，1），（foo，2），（foo，3）]，实际上。
索引列表会自动添加到内置索引中，每个列表元素都需要索引行。如果您有两个列表，每个列表包含5个元素，则内置索引中将需要10个索引行。
如果使用自定义索引在多个列表属性或多次相同的列表属性上定义索引，则会为每个唯一的项目组合编制索引。因此，具有两个列表a=[1,2,3]和b=[4,5,6]以及a和b上的索引的实体将生成索引条目[(1, 4), (1, 5), (1, 6), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6)]，并且具有一个列表c=[7,8,9,10]的实体和c上的索引两次将生成索引条目[(7, 8), (7, 9), (7, 10), (8, 9), (8, 10), (9, 10)]。这些是所谓的爆炸索引，而仅出现在自定义索引中，这些索引在给定索引中至少指定了两个列表属性实例。
未编制索引的列表属性仍然在实体协议缓冲区中占用相同的空间，并且仍然需要相同的时间来序列化和反序列化该PB，但是没有任何索引开销。