Différence de performances dans la requête entre cmd et workbench mysql

Sur la base du plan d'explication, l'optimiseur ne peut utiliser aucun index pour ORDER BY rent . Essayez donc ce qui suit :

1. Assurez-vous qu'un index existe à la rent_date colonne des rents table. Cet index sera utilisé pour optimiser le ORDER BY clause. Il peut s'agir d'un index à une seule colonne ou d'un index à plusieurs colonnes (utilisé dans d'autres scénarios). Mais, en cas de multi-colonne, vous devez vous assurer que le rent colonne est la première colonne dans l'ordre de l'index.
2. Assurez-vous qu'un index existe sur l'id colonne des kickscooters table. Les détails sur l'index à colonne unique / multi-colonne restent les mêmes qu'au point 1.
3. Assurez-vous qu'un index existe sur le serial_number colonne du kickscooter_states_190614 table. Les détails sur l'index à colonne unique / multi-colonne restent les mêmes qu'au point 1.

Maintenant, après avoir vérifié ces index, essayez votre requête d'origine. Très probablement, l'optimiseur devrait pouvoir optimiser l'ordre de jointure. En outre, la requête ci-dessus, vous pouvez appliquer l'ordre de jointure en utilisant STRAIGHT_JOIN indice d'optimisation. Alors, essayez également la requête suivante et comparez les deux :

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;