一般碰到问题都会有一个疑问,说这是谁写的SQL,应该快速重构,但是大部分优化场景都是:优化可以做,但业务不能停。 所以重构需要,但是不是现在。
那就是里面有一个明显全表扫描的逻辑,也就意味着尽管这么多表关联,但是数据量也可以接受,在优化器解析时大部分逻辑是走了索引,优化好最后一个全表扫描,整个问题就迎刃而解了。
目标看起来很简单,但是让人开始纠结的是里面的都是left join,怎么破?
但是在进一步和业务沟通,了解了业务的实现细节,发现整个逻辑似乎和我们理解的不大一样。
当然沟通的过程中,也进一步理解了需求,其实我们所谓的逻辑幂等,不是真正意义上的业务逻辑幂等。
从业务逻辑幂等上,是按照表tag的输出为标准。