我在mysql中有这个查询，因为它需要20秒来执行，所以我想做一些选择，而不是限制innerjoin，以使执行更快。
SELECT t1.order_id, CONCAT(t3.first_name,' ',t3.last_name),
buyer_first_name, buyer_last_name,
max(product_quantity) as product_quantity, order_status,
order_value, t5.first_name staff_firstnamelogin,
t5.last_name staff_lastnamelogin, t6.day_name
FROM t_seller_order t0
INNER JOIN t_orders t1
ON t0.event_id = t1.event_id
AND t1.seller_order_token = t0.seller_order_token
INNER JOIN t_tickets t2
ON t1.order_id = t2.order_id
INNER JOIN t_login t3
ON t3.login_id = t1.login_id
INNER JOIN t_login t5
ON t0.login_id = t5.login_id
INNER JOIN t_event_days t6
ON t2.product_id = t6.event_day_id
WHERE t0.event_id = 35
group by t1.order_id
order by order_id desc;
1条答案
按热度按时间yhxst69z1#
模式中有许多因素会阻碍查询的速度。让我们看看能做什么不能做什么。。。
自从
WHERE以及GROUP BY打不同的表，没有索引对两者都有用。最好的是有t0:INDEX(event_id).连接的索引：t2..t6需要上的索引（或pks）
order_id,login_id,event_day_id.t1需要INDEX(event_id, seller_order_token)以任何顺序。这个
GROUP BY以及ORDER BY是相同的，所以只需要一种，而不是两种。一个潜在的加速是完成
GROUP BY在做一些JOINs. 当前的结构是“充气-放气”，其中JOINs合谋创建一个巨大的临时表，然后GROUP BY缩小结果。所以。。。如果你能写一个
SELECT这样地：有多快？希望我们可以围绕这个构建其余的查询，但不需要花费太多时间。有两种方法；我不知道哪个更好。
计划a：使用子查询（如果可能）而不是
JOINs. 例如JOINing to t3, plan on this being one item in the选择“”：（表中的任何其他列也一样）
SELECT只碰一次table。从目前的情况来看，t5被触摸了两次，因此这种方法可能是不切实际的。）方案b：
JOIN之后GROUP BY. 也就是说，之后“放气”。举你的例子，我倾向于b计划，但两个“计划”的混合可能是可取的。
进一步说明：
LEFT JOIN以及LIMIT在上述讨论中添加皱纹。既然你们两个都没有，我就不跟他们讨论了。