Оптимизируйте страницу ранжирования с помощью PHP и MySQL.

Мне действительно не помешала бы помощь в оптимизации таблицы на моем веб-сайте, которая используется для отображения рейтинга. Я много читал о том, как оптимизировать запросы и как правильно использовать индексы, но даже после внесения изменений, которые, как я думал, будут работать, можно увидеть небольшое улучшение. Мое быстрое решение состояло в том, чтобы просто использовать только 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. Если вам нужна дополнительная информация, просто дайте мне знать.


person alexbaumhoer    schedule 12.08.2010    source источник
comment
Хорошая попытка Пони. Мы знаем, что вы имеете в виду хорошо. :-)   -  person bobs    schedule 12.08.2010
comment
Я знал, что что-то не так. Исправлена.   -  person alexbaumhoer    schedule 12.08.2010


Ответы (3)


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

Другие запросы выиграют от индекса по региону. Однако, подобно тому, что указывает @Matt, составной индекс по региону, стране и баллам может быть лучшим выбором. Обратите внимание, что в трех столбцах для ключа должны быть указан регион, страна и последовательность баллов.

person bobs    schedule 12.08.2010
comment
Спасибо за ответ, но я уже пытался использовать этот индекс. Это определенно в 10 раз быстрее, чем полное сканирование таблицы, но не показывает скорость, которая мне нужна при поиске стран, в частности. Если это лучший индекс для использования, возможно, проблема просто сводится к тому, что у вас нет достаточно мощного сервера для размещения этой базы данных? - person alexbaumhoer; 12.08.2010
comment
Из того, что вы предоставили, кажется, что этот индекс был бы лучшим. Бывают ли случаи, когда в запросе есть фильтр по стране, но нет фильтра по региону? Если да, то индекс по региону, вероятно, предоставит лучшее решение для этого типа запроса. Я не согласен с утверждением Слишком много индексов замедлят работу. Вы хотите создать правильный индекс(ы), а это может означать более одного. - person bobs; 12.08.2010

поставить ОДИН индекс по стране, баллу, региону. Слишком много индексов замедлит вас.

person Matt Williamson    schedule 12.08.2010

О каком количестве рекордов идет речь?

Я не гуру SQL, но в этом случае, если просто изменения индексов не помогли. Я бы подумал о том, чтобы поиграть со структурой таблицы, чтобы увидеть, какой прирост производительности я могу получить.

Кэш

id (pk)
LocationId (index)
name
оценка

Место нахождения

LocationId (pk)
CountryId (index) возможно
RegionId (index) возможно

Страна

CountryId
имя

Область, край

RegionId
имя

Место нахождения

LocationId (первичный ключ) CountryId
RegionId

Страна

Идентификатор страны

Область, край

Идентификатор региона

Временные таблицы в Procs позволят вам в каждом случае выбирать идентификатор местоположения. Это уменьшит общую сложность проблемы, с которой вы столкнулись: вы будете устранять неполадки 1 плана запроса, а не 3.

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

Удачи

person brian chandley    schedule 12.08.2010
comment
Мы говорим о более чем 850 000 записей и увеличиваемся примерно на 2 500 в день. Я запомню этот ответ на то время, когда у меня будет время реструктурировать таблицы. - person alexbaumhoer; 12.08.2010