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

Question

У меня есть два вопроса:

1. Какой заголовок более эффективен для выполнения большого запроса на большом объеме данных?

Я смотрел наMySQL doc, который объясняет производительность рабочего места в https://www.mysql.com/products/workbench/performance/, однако я не могу найти какой-либо ресурс, который конкретно говорит о разнице в эффективности между выполнением запроса на cmd и запросом на рабочем месте.

Как оптимизировать этот запрос

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
join rents r
  on k.id= r.kickscooter_id
join kickscooter_states_190614 k_st
  on k.serial_number = k_st.serial_number
order by r.rent_date
limit 999;

Я узнал, что создание индекса позволяет MySQL быстро сортировать вещи, поэтому я добавил индекс

ALTER TABLE `tablename` ADD INDEX `indexname` (`columnname`);

следующие ответы от одного из SO постов "упорядочить по" занимают слишком много времени в mysql

Как указано в комментариях, я выполнил

analyze <my query> 

, поскольку мой сервер - MariaDB.

, который дал мне КОД ОШИБКИ 2013: потеря соединения с сервером во время запроса.

Когда я запустил

explain <my query>

Это сработало и выдает:

id    select_type   table   type          possible_keys                                                  
1     SIMPLE        k_st    ALL  kickscooter_states_190614_serial_number_date_index             
1     SIMPLE        k       ref  PRIMARY,kickscooters_serial_number_unique,kickscooters_serial_number_index     
1     SIMPLE        r        ref    rents_kickscooter_id_foreign    

-table continued
/       key                       key_len      ref                        rows         extra

        null                        null       null                      192818947      Using temporary; Using filesort
   kickscooters_serial_number_unique 27     kickgoing_db.k_st.serial_number 1   
    rents_kickscooter_id_foreign     4      kickgoing_db.k.id              143  

Answer 1

На основе плана объяснения оптимизатор не может использовать какой-либо индекс для ORDER BY rent. Поэтому попробуйте следующее:

1. Убедитесь, что для столбца rent_date таблицы rents существует индекс. Этот индекс будет использоваться для оптимизации предложения ORDER BY. Это может быть индекс с одним столбцом или с несколькими столбцами (используется в других сценариях). Но в случае с несколькими столбцами необходимо убедиться, что столбец rent является первым столбцом в порядке индекса.
2. Убедитесь, что для столбца id в * 1012 существует индекс* Таблица. Сведения об индексе одного столбца / нескольких столбцов остаются такими же, как в пункте № 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;