Разлика в производителността в заявката между cmd и workbench mysql

Въз основа на плана Explain оптимизаторът не може да използва никакъв индекс за ORDER BY rent . Така че опитайте следното:

1. Уверете се, че на rent_date съществува индекс колона от rents маса. Този индекс ще се използва за оптимизиране на ORDER BY клауза. Може да бъде индекс с една колона или с няколко колони (използва се в други сценарии). Но в случай на такава с няколко колони, трябва да се уверите, че rent колоната е първата колона в реда на индекса.
2. Уверете се, че в id съществува индекс колона на kickscooters маса. Подробностите за индекса с една колона/много колони остават същите като в точка №1.
3. Уверете се, че в serial_number съществува индекс колона на kickscooter_states_190614 маса. Подробностите за индекса с една колона/много колони остават същите като в точка №1.

Сега, след като осигурите тези индекси, опитайте оригиналната си заявка. Най-вероятно оптимизаторът трябва да може да оптимизира поръчката за присъединяване. Освен това, с горната заявка, можете да наложите реда на присъединяване, като използвате STRAIGHT_JOIN съвет за оптимизатор. Така че, опитайте и следната заявка и направете сравнение между двете:

select
  r.user_id,
  k.id as kickscooter_id,
  st_astext(k.location) as location,
  k.created_at,
  k.serial_number,
  k_st.serial_number as states_serial_number,
  st_astext(k_st.gps) as gps_location,
  k_st.gps_updated_at,
  r.start_time,
  r.end_time
from kickscooters k
straight_join rents r
  on k.id= r.kickscooter_id
straight_join kickscooter_states_190614 k_st
  on k.serial_number = k_st.serial_number
order by r.rent_date
limit 999;