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

Question

Вот запрос (в самой большой таблице около 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 и из командной строки. В обоих местах было очень медленно с ORDER BY.

РЕДАКТИРОВАТЬ: Tolgahan ALBAYRAK решение работает, но кто-нибудь может объяснить, почему оно работает?

Answer 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

Answer 2

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

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

Answer 3

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

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

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

приписка Ответ Толгахана Албайрака, хотя и правильный для этого вопроса, не даст желаемого результата в тех случаях, когда выполняется запрос «LIMIT x».

Answer 4

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

Answer 5

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

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

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

Answer 6

Подобный вопрос был задан ранее здесь.

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

Answer 7

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