MySQL оптимизация для большой базы данных

Question

Я создаю веб-приложение для электронной коммерции, используя PHP и MYSQL (MYISAM). я хочу знать, как ускорить мои запросы

У меня есть таблица продуктов с более чем миллионом записей со следующими столбцами: id (int, primary) catid (int) usrid (int) title (int) описание (int) статус (enum) дата (datetime)

недавно я разбил эту одну таблицу на несколько таблиц на основе категорий продуктов (Catid). думая, что это может снизить нагрузку на сервер.

Теперь мне нужно получить результаты из этих таблиц в сочетании со следующими наборами условий 1. Результаты, соответствующие usrid и состоянию. (чтобы получить товары пользователя) 2 результата, соответствующих статусу и названию или описанию (например: для поиска товара)

теперь в настоящее время мне нужно использовать UNION для получения результатов из всех этих комбинированных таблиц, что замедляет производительность, и я также не могу применить LIMIT к комбинированному набору результатов. Я думал о создании индекса для всех этих столбцов, чтобы ускорить поиск, но это может замедлить вставки и обновления. Кроме того, я думаю, что разделение стола не было хорошей идеей.

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

Answer 1

Для запуска: загрузить тест и включить Журнал медленных запросов MySQL .

Некоторые другие предложения:

При использовании отдельных таблицдля каждой категории используйте UNION ALL вместо UNION.Причина в том, что UNION подразумевает особенность, которая заставляет ядро ​​базы данных выполнять дополнительную работу по ненужной дедупликации строк.

Индексы добавляют штраф за запись, но то, что вы описываете, вероятно, имеет отношение чтения-записи как минимум 10 к 1 и, вероятно, больше похоже на 1000 к 1 или выше.Итак, индекс.Для двух описанных вами запросов я бы, вероятно, создал три индекса (вам нужно изучить планы объяснения, чтобы определить, какой порядок столбцов лучше).

1. usrid и status
2. status и title
3. status и description (это индексируемое поле?)

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

Answer 2

Рассматривали ли вы использование memcached? Он кэширует набор результатов запросов к базе данных на сервере и возвращает их, если они запрашиваются несколькими пользователями. Если он не найдет набор результатов кэша, только тогда он запросит базу данных. Это должно значительно снизить нагрузку на базу данных.

http://memcached.org/