1.标识符错误
今天碰到一个很简单的SQL报错：标识符无效
可以看到所有的字段都变成了count(),不应该保留原来字段的基础上括起来再加count()吗？
难道是因为错误的将其优化没了？
实际上这就是MP的SQL日志表达形式，改成count（*）本质上还是查的你指定的数据
如果报错了：
一定是你SQL写错了，很明显，intxxxname是select的as完的字段名，所以明显不能用于where
2.查询结果page的total 不等于 实际条数？
首先明确一点，实际获取数据、total逻辑都是分开处理的，因为比如现在进行分页查询，size = 10，而total是实际满足条件的数据总数，所以一定是分开处理的
而MP的统计逻辑为 清理无关sql，比如select字段替换为count(*),
left join 表会直接忽略（因为MP认为被左关联的表只是关联出新数据，不会影响实际total）
不满足条件的动态sql直接忽略
但是我们知道左关联的本质是先进行笛卡尔积再关联，所以左关联的查询结果数完全是可能大于主表的
但是MP统计total按照“完美笛卡尔积”进行处理了
导致以下问题：
第29页显示四条数据，但实际上前端取的total是283，所以可以确定是MP不对应的原因（debug也证明了）
total- debug
找到total引用处，断点
直接看引用往往看不出访问位置，因为如果没有set那就是通过构造赋值的（注意构造可不一定是用户调用，不在运行时debug看不出来）
debug
一共进来5次，最后一个的栈
聚焦
MP优化后的countSQL，可以到所有left join都被忽略了
对比xml-sql：
改成上面的全关联的total和实际数目就能对上了（同于MP优化逻辑了）
所以on关联关系要根据实际业务编写，而不是AB有哪些字段同意义能作为外键就直接关联了（当然这是最基础的）
:::color5
上面就是因为没有限制产品类型，导致同一个dealno，在sete和dldt中都关联到了一条
而对于获取的sete业务，明显dealno应当是唯一的（仅涉及本业务），所以这里缺少了关联关系
:::
至于为什么左关联的条件会影响实际条数，就联想笛卡尔积即可，千万别当左关联一定是左表当老大，关联数据不影响条数
（左关联直接理解成画图交集的方式完全不对（只是类似），要从笛卡尔积原理出发）
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！