Оптимизировать страницу рейтинга, используя PHP и MySQL - PullRequest
1 голос
/ 12 августа 2010

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

Ответы [ 3 ]

2 голосов
/ 12 августа 2010

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

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

0 голосов
/ 12 августа 2010

Сколько записей мы говорим?

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

Cache

id (pk)
LocationId (индекс)
Имя
оценка

Расположение

LocationId (pk)
CountryId (индекс) может быть
RegionId (индекс) может быть

Страна

CountryId
Имя

Регион

RegionId
имя

Местоположение

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

Страна

CountryId Имя

Регион

RegionId Имя

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

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

Удачи

0 голосов
/ 12 августа 2010

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

...