MySQL Slow на соединении. Любой способ убыстриться

По большей части вы также должны индексировать любой столбец, который используется в JOIN. В вашем случае вы должны проиндексировать как listentrack.url , так и music.url

@jeff s - индекс music.date_created не поможет, потому что вы сначала запускаете его через функцию, поэтому MySQL не может используйте индекс в этом столбце. Часто, вы можете переписать запрос так, чтобы индексированный столбец, на который указывает ссылка, использовался статически, например:

DATEDIFF(DATE(date_created),'2009-08-15') = 0

становится

date_created >= '2009-08-15' and date_created < '2009-08-15'

Это отфильтрует записи, относящиеся к 2009-08-15, и позволит любым индексам в этом столбце быть кандидатами. Обратите внимание, что MySQL НЕ может использовать этот индекс, это зависит от других факторов.

Лучше всего создать двойной индекс на listentrack (url, date_created) а затем еще один индекс на music.url

Эти два индекса будут охватывать этот конкретный запрос.

Обратите внимание, что если вы запустите EXPLAIN для этого запроса, вы все равно получите ] с помощью filesort , потому что он должен записывать записи во временную таблицу на диске, чтобы выполнить ORDER BY.

В общем, вы всегда должны запускать свой запрос в EXPLAIN , чтобы получить представление о том, как MySQL будет выполнять запрос, а затем перейти оттуда. См. Документацию EXPLAIN :

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

Попробуйте создать индекс, который поможет с объединением:

CREATE INDEX idx_url ON music (url);

Думаю, раньше я мог упустить очевидное. Почему ты вообще садишься за музыкальный стол? Кажется, что вы вообще не используете данные в этой таблице, и вы выполняете левое соединение, которое не требуется, право? Я думаю, что эта таблица в запросе сделает его намного медленнее и не принесет никакой пользы. Удалите все ссылки на музыку, если только включение URL-адреса не требуется, и в этом случае вам нужно правильное соединение, чтобы заставить его не включать строку без совпадающего значения.

Я бы добавил новые индексы, как упоминают другие. В частности, я бы добавил: музыкальный URL listentrack date_created, url

Это значительно улучшит ваше соединение.

Тогда я бы посмотрел на запрос, вы заставляете систему выполнять работу с каждой строкой таблицы. Было бы лучше перефразировать ограничение даты как диапазон.

Не уверен в синтаксисе, который у меня в голове: где '2009-08-15 00:00:00' <= date_created <2009-08-16 00:00:00

Это должно позволить ему быстро использовать индекс для поиска соответствующих записей. Объединенный двухключевой индекс музыки должен позволить ему находить записи по дате и URL. Вы должны поэкспериментировать, им может быть лучше пойти в другом направлении url, date_created в индексе.

В плане объяснения для этого запроса должно быть указано «использование индекса» в правом столбце для обоих. Это означает, что ему не нужно будет обращаться к данным в таблице для вычисления ваших сумм.

Я бы также проверил настройки памяти, которые вы настроили для MySQL. Похоже, у вас недостаточно выделенной памяти. Будьте очень осторожны с различиями между настройками на основе сервера и настройками на основе потоков. Сервер с кеш-памятью 10 МБ довольно маленький,

Почему вы повторяете URL-адрес в обеих таблицах?

Пусть в listentrack вместо этого хранится music_id, и присоединяйтесь к нему. Избавляется от текстового поиска, а также от дополнительного индекса.

Кроме того, возможно, это более правильно. Вы отслеживаете время прослушивания определенной дорожки, а не URL-адрес. Что, если URL изменится?

После добавления индексов вы можете попробовать добавить новый столбец для date_created, который будет unix_timestamp, что ускорит математические операции.

Я не уверен, почему у вас есть diff, однако, похоже, вы ищете все строки, которые были обновлены на определенную дату.

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

Если вы используете модульные тесты, вы вместо этого можно сравнивать результаты вашего запроса и запроса, используя временную метку unix.

вы можете захотеть добавить индекс в поле url обеих таблиц.

сказав, что когда я преобразовал mysql на sql server 2008, с теми же запросами и теми же структурами базы данных запросы выполнялись на 1-3 порядка быстрее.

Я думаю, что некоторые из них были связаны с rdbms (оптимизаторы mysql не так хороши ...), а некоторые из них, возможно, были связаны с тем, как rdbms резервные системные ресурсы. хотя сравнения были сделаны в производственных системах, где могла работать только база данных.