Большие БД

ну не в вместо только))

sidorka, мыслей не особо, а почитать можно http://ruhighload.com/ про Mysql пара хороших статей и масштабирование.

зы. всегда есть какой-то задел по оптимизации запросов, нужно пробовать менять, может разбивать на несколько, мониторить время. и зачем вам CONCAT в запросе? лишними операциями БД грузануть? Я не эксперт mysql, и сам бы такой запрос никогда не написал, select в select дает реальное ускорение или в смысле "от перемены слагаемых сумма не меняется"?

Без детальной информации сложно будет чем-то помочь.

1) Информация о железе, настройки mysql (mysqltuner, например, вам в помощь), что еще работает на этом сервере и сколько берет ресурсов?

2) Детальная схема всех участвующих таблиц в запросе, включая индексы (на скриншотах их не видно).

3) Конкретный запрос. Очень тажке поможет результат explain по конкретному запросу.

А дальше уже можно говорить о SSD дисках, если выяснится, что узкое место - жесткий диск.

---------- Добавлено 07.07.2015 в 11:55 ----------

Без детальной информации сложно будет чем-то помочь.

1) Информация о железе, настройки mysql (mysqltuner, например, вам в помощь), что еще работает на этом сервере и сколько берет ресурсов?

2) Детальная схема всех участвующих таблиц в запросе, включая индексы (на скриншотах их не видно).

3) Конкретный запрос. Очень тажке поможет результат explain по конкретному запросу.

А дальше уже можно говорить о SSD дисках, если выяснится, что узкое место - жесткий диск.

totamon, это чтобы джоины облегчить. Я надеюсь, что понял правильно их работу. Кстати, прямо сейчас увидел еще косяк - NOT и != работает же без индексов вроде?

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

В общем вам правильно сказали, что без конкретных данных по архитектуре БД и выполняемых запросов - сложно что-то рекомендовать.

Из общего - диск побыстрее и в силу огромных размеров таблиц - оперативной памяти поболее. Смотрите на архитектуру, занимайтесь нормализацией таблиц.

100 миллионов строк - это не так много, чтобы обычные индексы не работали. Просто оптимизируйте индексы в своих запросах - разберитесь как они работает и создайте в таблицах нужные индексы и удалите ненужные. В крайнем случае используйте конструкцию USE INDEX

Я бы начал с изучения Explain (ссылка 1, ссылка 2 и также google в помощь), в плане архитектуры и с анализа и оптимизации mysql настроек с помощью mysqltuner

когда-то давно на очень слабом сервере работал с данными объемом 1 Гб MySQL-ISAM. Тормозило все, конечно, нереально. Тогда я разбил данные на несколько десятков таблиц (все автоматически) и проект заработал на том же слабом сервере☝

proksey-net, тоже пришел к такому решению. Буду пробовать.

Запросы к БД могут тормозит всего по двум причинам: перегруз диска и перегруз процессора.

Для начала опередите, что происходит в вашем случае. Если диск, то:

1) Если памяти меньше, чем размер БД, то однозначно масштаб выигрыша от SSD не будет сравним ни с чем другим.

Ответ на вопрос "как жили раньше без SSD" - в идеале ставили достаточно памяти, чтобы все индексы и большая часть базы в ней могли закешироваться.

2) Проверьте, чтобы для всех полей, которые участвуют в связях были построены индексы. Например, для вашего "JOIN keywords AS k ON k.id = p.keyword_id" надо, чтобы на keyword_id и id были индексы.

Если процессор, то пересмотрите все запросы с конструкциями distinct, group by, order by, и по возможности избавьтесь от запуска таких запросов на большом количестве данных.

Как вариант, кэшируйте в отдельных таблицах результаты group by.

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

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

Без структуры выборок сложно понять, по приведенному запросу - add_date timestamp - индекс? Различия с первичным ключем есть, или сортировка будет идентична?

Неясно, зачем джойны по 1 полю из других таблиц? Экономите на размерах таблиц?

Зачем выбирать Select * если в запросе нужно всего несколько полей?

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

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

Самое простое и правильное направление - EXPLAIN SELECT курить до полной оптимизации всего и вся.