"RT，看文档似乎这两个是等效的，但结果却不同，想请教一下原因。 [图片] [图片] [图片]"
RT，看文档似乎这两个是等效的，但结果却不同，想请教一下原因。
join 时关联字段应该是主键或者保证唯一（可以用多个字段做为联合主键），你这个用 a 和 c 做为主键，本身数据上就有问题。一：先保证数据正确吧。二：至于为啥做为序表 join 和做为游标 joinx 出的结果不一致，这个看下是否有大神解释下。
join 没这个要求，可以多对多，或者一对多。这个例子数据没什么问题。
join 是内存运算，一条记录可以多次反复匹配，可以支持多对多的情况。joinx 设计的是外存计算，游标流出来的记录不会反复使用了，无法支持多对多情况（可以支持一对多），碰到相同键值就会都向后走一格再匹配，不会回头了。
猜想可能是这样，但是看结果还是不理解。A4 按照您说的似乎应该是 A1 取一条（1,b2），同时 A2 取一条（1,d2）发现匹配得到 1,b2,1,d2; 然后游标往后 A2 再取一条（1,d4）, 还是匹配应该得到（1,b2,1,d4）；A2 再往后发现不匹配了，这时 A1 的游标往后也发现匹配不上, 再往后…但现在 A1 的第二条居然和 A2 的第二条匹配上了（1,b4,1,d4）这就不太理解了，左边或右边总要有一个为主等另一边遍历比对完游标才能继续移动。
另外，有序归并为什么不把 A1 A2 相同的键值（如等于 1）的记录都取出来进行内存运算，或者只把左边的相同键值一次性加载到内存，这样就可以处理多对多的情况呢？如果不能，想进行游标多对多运算要怎么算呢，用 xjoinx 再 select 吗？
等值多对多连接通常没有业务意义（极罕见的情况有意义），怎么处理都不重要了。内存时容易处理（处理它对性能影响很小），也就处理了，也可以用来应付较罕见的有意义的多对多。外存要处理多对多，基本上就是要游标回头才行了，这个对性能影响太大（逻辑上按游标定义也做不到），所以随便选择了一种好处理的方式，SPL 也不对这种结果负责，某天可能会换用其它成本低的方式，所以不必去猜测它是怎么做的（可以读源码理解）。SPL 只会保证多对一和一对多以及一对一时的运算结果。
我们不能假定相同键值的数据在内存中可以放下（虽然大部分情况是可以的），即使不考虑性能损失，也不能自动这么处理。在这种假定下，可以用 cs.group 读出来自己处理。游标上不能实现多对多，理由如前所述：对性能损失太大，而且极为罕见，划不来。如果有必要，还不如重新设计一个新函数来处理。很多运算在理论上是合理的，但工程实践上是另一回事，要考虑实现和应用成本以及投入这个成本后换来的好处是不是划得来。
http://c.raqsoft.com.cn/article/1619562709132对于 JOIN 的理解，读这一篇（及后续篇）。这也是 SPL 处理的等值 JOIN 的思路，针对键值的多对多不在考虑之内（信息系统中出现按键值的多对多，99% 可能性是搞错了）。有时候区间关联需要多对多，但通常是小数据，可以用内存的 join 和 xjoin 来处理。
感谢解答🙏
join 时关联字段应该是主键或者保证唯一（可以用多个字段做为联合主键），你这个用 a 和 c 做为主键，本身数据上就有问题。
一：先保证数据正确吧。
二：至于为啥做为序表 join 和做为游标 joinx 出的结果不一致，这个看下是否有大神解释下。
join 没这个要求，可以多对多，或者一对多。这个例子数据没什么问题。
join 是内存运算，一条记录可以多次反复匹配，可以支持多对多的情况。
joinx 设计的是外存计算，游标流出来的记录不会反复使用了，无法支持多对多情况（可以支持一对多），碰到相同键值就会都向后走一格再匹配，不会回头了。
猜想可能是这样，但是看结果还是不理解。A4 按照您说的似乎应该是 A1 取一条（1,b2），同时 A2 取一条（1,d2）发现匹配得到 1,b2,1,d2; 然后游标往后 A2 再取一条（1,d4）, 还是匹配应该得到（1,b2,1,d4）；A2 再往后发现不匹配了，这时 A1 的游标往后也发现匹配不上, 再往后…
但现在 A1 的第二条居然和 A2 的第二条匹配上了（1,b4,1,d4）这就不太理解了，左边或右边总要有一个为主等另一边遍历比对完游标才能继续移动。
另外，有序归并为什么不把 A1 A2 相同的键值（如等于 1）的记录都取出来进行内存运算，或者只把左边的相同键值一次性加载到内存，这样就可以处理多对多的情况呢？如果不能，想进行游标多对多运算要怎么算呢，用 xjoinx 再 select 吗？
等值多对多连接通常没有业务意义（极罕见的情况有意义），怎么处理都不重要了。内存时容易处理（处理它对性能影响很小），也就处理了，也可以用来应付较罕见的有意义的多对多。外存要处理多对多，基本上就是要游标回头才行了，这个对性能影响太大（逻辑上按游标定义也做不到），所以随便选择了一种好处理的方式，SPL 也不对这种结果负责，某天可能会换用其它成本低的方式，所以不必去猜测它是怎么做的（可以读源码理解）。SPL 只会保证多对一和一对多以及一对一时的运算结果。
我们不能假定相同键值的数据在内存中可以放下（虽然大部分情况是可以的），即使不考虑性能损失，也不能自动这么处理。在这种假定下，可以用 cs.group 读出来自己处理。
游标上不能实现多对多，理由如前所述：对性能损失太大，而且极为罕见，划不来。如果有必要，还不如重新设计一个新函数来处理。
很多运算在理论上是合理的，但工程实践上是另一回事，要考虑实现和应用成本以及投入这个成本后换来的好处是不是划得来。
http://c.raqsoft.com.cn/article/1619562709132
对于 JOIN 的理解，读这一篇（及后续篇）。这也是 SPL 处理的等值 JOIN 的思路，针对键值的多对多不在考虑之内（信息系统中出现按键值的多对多，99% 可能性是搞错了）。有时候区间关联需要多对多，但通常是小数据，可以用内存的 join 和 xjoin 来处理。
感谢解答🙏