Diferencia de rendimiento en la consulta entre cmd y workbench mysql

Según el plan de explicación, el optimizador no puede usar ningún índice para ORDER BY rent . Así que intente lo siguiente:

1. Asegúrese de que exista un índice en el rent_date columna de los rents mesa. Este índice se utilizará para optimizar el ORDER BY cláusula. Puede ser un índice de una sola columna o uno de varias columnas (usado en otros escenarios). Pero, en el caso de una de varias columnas, debe asegurarse de que rent columna es la primera columna en el orden del índice.
2. Asegúrese de que exista un índice en el id columna de los kickscooters mesa. Los detalles sobre el índice de columna única/columna múltiple siguen siendo los mismos que en el punto n.º 1.
3. Asegúrese de que exista un índice en el serial_number columna de kickscooter_states_190614 mesa. Los detalles sobre el índice de columna única/columna múltiple siguen siendo los mismos que en el punto n.º 1.

Ahora, después de asegurar estos índices, intente su consulta original. Lo más probable es que el optimizador pueda optimizar la orden de unión. Además, la consulta anterior, puede hacer cumplir el orden de unión usando STRAIGHT_JOIN sugerencia del optimizador. Entonces, intente la siguiente consulta también y haga un benchmark entre los dos:

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;