Diferença de desempenho na consulta entre cmd e mysql do workbench

Com base no plano Explain, o otimizador não pode usar nenhum índice para ORDER BY rent . Então tente o seguinte:

Certifique-se de que existe um índice em rent_date coluna dos rents tabela. Este índice será usado para otimizar o ORDER BY cláusula. Pode ser um índice de coluna única ou de várias colunas (usado em outros cenários). Mas, no caso de multi-colunas, você precisa garantir que o rent coluna é a primeira coluna na ordem do índice.
Certifique-se de que existe um índice no id coluna dos kickscooters tabela. Os detalhes sobre o índice de coluna única/várias colunas permanecem os mesmos do ponto 1.
Certifique-se de que existe um índice no serial_number coluna do kickscooter_states_190614 tabela. Os detalhes sobre o índice de coluna única/várias colunas permanecem os mesmos do ponto 1.

Agora, depois de garantir esses índices, tente sua consulta original. Muito provavelmente, o otimizador deve ser capaz de otimizar o Join Order. Além disso, na consulta acima, você pode impor a ordem de associação usando STRAIGHT_JOIN dica do otimizador. Então, tente a seguinte consulta também e faça um benchmark entre os dois:

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;