mysql distinct 效率_symfon2中生成的sql语句带有DISTINCT,效率很慢?

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其他语句的执行,这是在线系统数据库最应该避免的。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值