Медленный запрос при использовании ORDER BY

Здесь запрос (наибольшая таблица содержит около 40 000 строк)

SELECT
  Course.CourseID,
  Course.Description,
  UserCourse.UserID,
  UserCourse.TimeAllowed,
  UserCourse.CreatedOn,
  UserCourse.PassedOn,
  UserCourse.IssuedOn,
  C.LessonCnt
FROM
  UserCourse
INNER JOIN
  Course
USING(CourseID)
INNER JOIN
(
  SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID
) C
USING(CourseID)
WHERE 
  UserCourse.UserID = 8810

Если я запустил это, он выполняется очень быстро (приблизительно 0,05 секунды). Он возвращает 13 строк.

Когда я добавляю предложение ORDER BY в конце запроса (упорядочение по любому столбцу), запрос занимает около 10 секунд.

Теперь я использую эту базу данных в производстве, и все работает нормально. Все мои другие запросы быстрые.

Любые идеи о том, что это может быть? Я выполнил запрос в MySQL Query Browser и из командной строки. Оба места были медленными с помощью ORDER BY.

EDIT: Решение Tolgahan ALBAYRAK работает, но может ли кто-нибудь объяснить, почему он работает?

Ответ 1

возможно, это помогает:

SELECT * FROM (    
     SELECT
      Course.CourseID,
      Course.Description,
      UserCourse.UserID,
      UserCourse.TimeAllowed,
      UserCourse.CreatedOn,
      UserCourse.PassedOn,
      UserCourse.IssuedOn,
      C.LessonCnt
    FROM
      UserCourse
    INNER JOIN
      Course
    USING(CourseID)
    INNER JOIN
    (
      SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID
    ) C
    USING(CourseID)
    WHERE 
      UserCourse.UserID = 8810
) ORDER BY CourseID

Ответ 2

Является ли упорядоченный столбец индексированным?

Индексация значительно ускоряет упорядочивание и фильтрацию.

Ответ 3

Реализовать ответ слишком поздно, но у меня была аналогичная проблема, добавив порядок, увеличив время запроса с секунд до 5 минут и попробовав большинство других предложений по его ускорению, заметил, что файлы /tmp, для этого запроса будет 12G. Изменил запрос таким образом, что возвращаемое поле varchar (20000) было "trim" ("ed и производительность значительно улучшились (назад к секундам). Поэтому я считаю, что стоит проверить, возвращают ли вы большие varchars как часть вашего запроса, и если да, обрабатывать их (может быть, подстрока (x, 1, length (x))? Если вы не хотите их обрезать. Запрос возвращал 500 тыс. Строк, а файл /tmp указывал, что каждая строка использует около 20 тыс. Данных.

Ответ 4

Вы выбираете из " UserCourse", который, я полагаю, является таблицей объединения между курсами и пользователями (от многих до многих). Вы должны индексировать столбец, который вам нужно заказать, в таблице "UserCourse".

Предположим, что вы хотите " заказать по CourseID", тогда вам нужно проиндексировать его в таблице UserCourse.

Заказ любого другого столбца, который отсутствует в таблице соединения (например, UserCourse), может потребовать дальнейшей денормализации и индексации в таблице соединения, которая должна быть оптимизирована для скорости; Другими словами, вам нужно иметь копию этого столбца в таблице соединений и индексировать его.

P.S. Ответ Tolgahan Albayrak, хотя и правильный для этого вопроса, не принесет желаемого результата, в тех случаях, когда вы делаете запрос "LIMIT x".

Ответ 5

Вы обновили статистику своей базы данных? Я столкнулся с чем-то похожим на моем, где у меня было 2 одинаковых вопроса, где единственная разница была заглавная буква, а одна возвращалась через 1/2 секунды, а другая заняла около 5 минут. Обновление статистики позволило решить проблему

Ответ 6

Аналогичный вопрос был задан до здесь.

Это может помочь вам. В основном это описывает использование составных индексов и порядок работы.

Ответ 7

Сегодня у меня возникла такая же проблема. Как только я сортировал набор результатов по полю из объединенной таблицы, весь запрос был ужасно медленным и занял более ста секунд.

Сервер выполнял MySQL 5.0.51a, и я случайно заметил, что тот же запрос работает так же быстро, как это всегда должно выполняться на сервере с MySQL 5.1. При сравнении объяснений для этого запроса я видел, что очевидно, что использование и обработка индексов сильно изменились (по крайней мере, от 5.0 до > 5.1).

Итак, если вы столкнулись с такой проблемой, возможно, ваше решение - просто обновить MySQL