这个地方是一处 explain 结果显示上面的 bug，并不是真正的统计信息用的不准
在 IndexHashJoin 的 Probe 侧的这个 estRows 只有 2.16，这个是估算的执行一次的代价
实际上 IndexLookUp_153(Probe) 这个要执行 4460440.32 次！
所以 2.16 3.57 这些数字都应该显示成 ? x 4460440.32 才是真正的 estRows
这个 2.16 之类的 estRows 的估算，确实如 @h5n1 和 @人如其名 说的，是通过 1 / NDV 这样的 distinct 的方式计算的。
另外，如果这个场景下是 ignore index 走 scan 的方式比回表要快的话，那么也不是统计信息的问题，而是说我们对回表的代价假设得过低了一点。真实场景里面如果回表 scan 要涉及的 store / region 太多的话，会生成特别多的分散的 distsql 请求，这种行为的性能是比较低下来，往往还不如 scan 的顺序扫方式。
(或者可以类比一下，随机 io 特别多的时候，跟顺序 io 扫的量比较大，后者可能还快一点)