Я мог действительно использовать некоторую справку, оптимизируя таблицу на моем веб-сайте, который используется для отображения рейтингов. Я читал много о том, как оптимизировать запросы и как правильно использовать индексы, но даже после реализации изменений я думал, будет работать, мало улучшения видно. Мое быстрое исправление должно было просто использовать только лучшие 100 000 рейтингов (обновляемый ежедневно, и сохранил в другой таблице) улучшить скорость на данный момент, но мне действительно не нравится та опция.
Таким образом, у меня есть таблица, которая хранит информацию для пользователей, которая смотрит что-то как:
таблица 'кэш':
id (Primary key)
name
region
country
score
Существуют другие переменные, сохраненные о пользователе, но я не думаю, что они релевантны здесь, поскольку они не используются в рейтингах.
Существует 3 основных страницы рейтинга, которые может просмотреть пользователь:
Мировоззрение:
SELECT cache name,region,country,score FROM cache ORDER BY score DESC LIMIT 0,26
Представление региона:
SELECT name,region,country,score FROM cache WHERE region='Europe' ORDER BY score DESC LIMIT 0,26
и представление страны:
SELECT name,region,country,score FROM cache WHERE region='Europe' AND country='Germany' ORDER BY score DESC LIMIT 0,26
Я попробовал почти каждую комбинацию индексов, о которых я могу думать, чтобы помочь облегчить работу для базы данных, и в то время как некоторые, кажется, помогают немногому, я не могу найти тот, который только возвратит 26 строк и для запросов региона и для страны (только с индексом на 'счете', мировые рейтинги сверкают быстро).
Я чувствую, что мог бы пропускать что-то основное, любая справка будет очень цениться!
Мало дополнительной информации: таблица кэша в настоящее время - приблизительно 920 мегабайтов с немного больше чем 800 000 общих количеств строк. Если Вы могли бы больше использовать информацию, просто сообщает мне.
Ваш мировой рейтинг выигрывает от индекса оценки, потому что оценка является единственным критерием в запросе. Логическая последовательность, по которой выполняется сортировка, встроена в запрос. Так что хорошо.
Для других запросов будет полезен индекс по региону. Однако, подобно тому, что указывает @Matt, составной индекс по региону, стране и баллу может быть лучшим выбором. Обратите внимание, что в трех столбцах ключа должны быть указаны регион, страна и последовательность оценок.
О скольких записях идет речь?
Я не гуру SQL, но в данном случае простое изменение индексов не поможет. Я бы подумал поиграть со структурой таблицы, чтобы увидеть, какой прирост производительности я могу получить.
идентификатор (pk)
LocationId (индекс)
имя
оценка
LocationId (pk)
CountryId (индекс) может быть
RegionId (индекс) может быть
CountryId
имя
Идентификатор региона
имя
LocationId (Первичный ключ)
CountryId
RegionId
CountryId имя
RegionId name
Временные таблицы в Procs позволят вам выбрать идентификатор местоположения в каждом случае. Это снизило бы общую сложность проблемы, с которой вы столкнулись: вы будете устранять неполадки в одном плане запроса, а не в 3.
Усилия будут высоки, а окупаемость будет до тех пор, пока вы не закончите, поэтому я бы посоветовал взглянуть на индексный подход в первую очередь.
Удачи
поместите ОДИН индекс для страны, показателя, региона. Слишком много индексов замедлит вас.