Помогите настроить связку Mysql Apache Nginx

Ах.. мистика. С 4.9 сек до 0.0005. Поставил индекс на auth+authprov+proto т.к. это вместе характеризует сборку клиента игры.

Хотя вообще я тут чего-то не понимаю.

Всегда индекс использовал id auto_increment для однозначного определения строки и ее редактирования/удаления в CMS и только раз надо было из одинаковых таблиц на нескольких источниках свести данные в одну - ставил unique на id (auto_increment)+id источника чтобы не путались. Больше с индексами работать не приходилось и все сорцы которые ковырял - нигде не видел больше 1 индекса...

Завтра в пике посмотрю на результат и отпишу. Всем спасибо.

Metal_Messiah, Основные понятия БД.

Кластерные и «обычные» индексы MySQL

Оптимизация сложных запросов MySQL

Сейчас нагрузка вдвое выше той что клала сервер, визуально тормоза не заметны. Всем спасибо.

Есть еще медленные запросы но их за 3 дня набралось 25.

Очень у многих auth, authprov и proto одинаковые.

В результате если строка найдена:

# Query_time: 15.097846 Lock_time: 0.000041 Rows_sent: 1 Rows_examined: 15218

если не найдена идет проход по всей таблице

# Query_time: 19.431725 Lock_time: 0.000058 Rows_sent: 0 Rows_examined: 736856

и то и то записано в slow query log (хотя странно, там количество строк в 50 раз больше, но время больше только в 1.3 раза)

Делать индекс по name (VARCHAR) не думаю что есть смысл. Или есть? Говорят что индексы по строкам тормозят.

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

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

Или у вас за каждый медленный запрос по пальцу отсекают?

Говорят.

Так же говорят, что можно делать индекс по части строки. Или полнотекстовый индекс.

Теперь уже непонятно, что именно вы там сделали. Лучше новую ситуацию опишите : таблицы, индексы, запросы,explain.

Чтобы "отсекать пальцы" взвешенно, лучше пользоваться программами для обработки slow log : я рекомендую pt-query-digest.