我有一个大约 700k 行的表，每行都由一个唯一的 itemnumber 标识。
通过计算指示关联强度的单个数值或两个项目之间的数学“距离”，每行/项目可以与表中的任何其他行/项目相关联，没有关联/无限距离由“0”表示" 而数值“1”表示相同项目/无距离。
这些关联编号难以计算/计算密集并且基于存储在单独数据库中的数据。因此，为所有行组合预先计算一次，然后只为添加的新行（每年 <4k 新行）预先计算它们似乎是有道理的。
生成的关联表可能如下所示：
itemnumber | associatedwithitem | associationstrength
23920390293 | 12356456885 | 0.12255888644888
45468411516 | 44565464884 | 0.91155684161123
45648855222 | 98956221818 | 0.00000000000000
45468411516 | 23920390293 | 0.46813185844468
然而，这样一个表的大小将是巨大的：((700,000 x 700,000) - 700,000)/2 = 244.999.650.000 = 大约 2500 亿行，即使在丢弃所有自连接（公式中的 -700,000）并存储之后每个连接只有一种方式（公式中除以二）。
我将只运行一种类型的查询，如下所示：
“给定一个 itemnumber 列表（见上表示例），计算平均（mean）关联数。”
针对关联表运行的每个 itemnumber 列表通常包含 < 1k itemnumber，但很少会大到 50k。但是因为 1k 个 itemnumber 的列表中的每个数字都将与 700k 个其他 itemnumber 相关联，这样的查询将提取 700,000 x 1000 = 700,000,000 个关联号，然后需要计算这 700m 个关联号的平均值。
对以下方面的任何想法：