生成的sql带有distict导致查询效率下降

tuser_recharge.user_id 看上去必是 user.id 的子集，你在tuser_recharge(1.5m)上做DISTINCT，再怎么JOIN也没什么用，况且两个语句并不从user表关联取值，所以JOIN是多余的。

但真正的问题还是在tuser_recharge的数据量，1.5m数据作DISTINCT，哪怕user_id有索引也不影响DISTINC的执行，mysql会遍历整个索引，1.5m记录，假设索引里单记录执行花费0.00001秒，光遍历索引就需要大概0.000001x1500000=1.5秒，你画出的第一条语句的执行结果就在这个数量级上。
这你可以直接跑
SELECT DISTINCT user_id
FROM tuser_recharge
来验证，速度会在一个数量级上。
第二条语句要慢很多，是因为除了遍历整个1.5m的索引，还需要产生临时表做SORT（因为ORDER BY），慢是可想而知的。
优化的思路，第一是看你是否有用WHERE的可能，即避免让DISTINCT遍历整个索引，而用WHER先缩小范围。
SELECT DISTINCT user_id
FROM tuser_recharge
WHERE col = xxx
如果业务不允许，那么最好的办法不是优化DINSTINCT，而是优化你的架构。通常操作思路是把前端代码和慢SQL语句解耦，做一个MYSQL SLAVE，用一个后台程序定时执行慢语句，把结果存入某个地方，前端语句直接读取这个结果，不经过mysql。这样的好处是前端不会再有伸缩性问题，坏处是牺牲了一定的实时性。如果你控制后台语句每一分钟执行一次，对一般业务也不至于产生什么问题。通常用户前端有一分钟或者几分钟的延迟并不是什么大问题。
这样做你在架构上的收益是最大的，因为一个慢语句的成本不只是这个慢语句本身，还会BLOCK其他语句的执行，这是在线系统数据库最应该避免的。