但要说明的是，上述Tip是客观情况造成（可接受），但本例却是例外，因此优化器实际上可以拿到能够作出选择正确结果的数据(rows值)，但是最终选择错误。
原因分析
MySQL优化器是按照查询代价的估算值，来确定要使用的索引。计算这个估算值的过程，基本是按照“估计需要扫描的行数”来确定的。
MySQL Tips：MySQL在目前集团主流使用的5.1和5.5版本中只能使用前缀索引。
因此，使用索引A只能用上字段f3，使用索引B只能用上字段f1。Rows即为使用了索引查到上下界，之后需要扫描的数据行数（估算值）。
上述的语句需要用到group和order by，因此执行计划中都有Using temporary; Using filesort。
流程上按顺序先计算使用索引A的查询代价。
之后依次计算其他possitabe_key的查询代价。由于过程中需要排序，在得到一个暂定结果后，需要判断是否有代价更低的排序方式(test_if_cheaper_ordering)。
与之前的大同小异，也是依靠估计扫描行数来计算代价。
在这个逻辑的实现过程中，存在一个bug：在估计当前索引的区分度的时候，没有考虑到前缀索引。
即：假设表中有50w行数据，索引B(f1,f2,f3)，则计算索引区分度时，需要根据能够用上的前缀部分来确定。比如f1有1000个不同的值，则平均每个key值上的记录数为500.如(f1,f2)有10000个同的值，则平均每个组合key上的记录数为50，若(f1,f2,f3)有50w个不同的值，则平均每个组合key上的记录数为1。
MySQL Tips：每个key上的记录数越少，说明使用该索引查询时效率最高。对应于show index from tbl 输出结果中的Cardinality值越大。
在这个case下，索引B只能使用f1做前缀索引，但是在计算单key上的行平均值时用的是(f1,f2,f3)，这就导致估算用索引B估算的时候，得到的代价偏小。导致误选。
回到问题本身
1、 为什么limit值大的时候反而选对了呢？
这是因为在计算B的查询代价时，查询需要返回的行数limit_rows也参与乘积，若limit值较大，则计算出来的B的代价就会更大，反而会由于代价。值超过A，而导致优化器最终选择A。
2、 这个表有50w行数就，为什么limit相差为就差别这么大？
这与语句本身有关。这个语句中有group by，这就意味着每多limit一个值，实际上需要扫描更多的行N。 这里N为“表的总行数”/“表中不同的f2值”。
也就是说这个语句使得这个bug有放大作用。
解决方案
分析清楚后解决方法就比较简单了，修改代码逻辑，在执行test_if_cheaper_ordering过程中，改用字段f1的区分度来计算即可。
