Какой способ оптимальный по SELECT в данной ситуации?

Question

[alexdora]

Дано:

1. Есть таблица 12млн записей (прирост в сутки 12-15к записей, изменения строк 1000-2000 в сутки)
   
2. id, exUrl (varchar 255), locUrl (varchar 255), innoDB
   
3. При генерации страницы нужно достать из базы всего 100-150 строк из этой таблицы
   
4. Таких запросов 60-100 в минуту
   
5. Всего на базе нагрузка realtime 600 соединений и приблизительно 700-800 запросов в секунду к другим таблицам
   
6. VPS XEN Ubuntu 14.04: 4 ядра + 8Gb Ram + SSD
   

Вот сижу и думаю, как наиболее оптимально выдергивать эти 100-150 строк. Пока вариант генерировать длинный запрос на поиск SELECT по id всех необходимых строк, но он мне не очень нравится.
Не смотря на довольно большое количество запросов/соединений к базе, там сплошные INSERT и поиски только по таблицам( в таблицах до 300к до 1млн записей). Поэтому нагрузка общая на систему 12%-14% в пике. У меня не получится тестировать в поле и смотреть - упадет или нет. Если база обрушится от этих запросов - то будет беда-беда-беда покруче всемирного потопа.

Answer 1

[Петр]

Оптимальнее memory cache на 150 записей. Если для всех страниц одинаковые записи.

Comments

[alexdora]

К сожалению там выборка каждый раз случайна. Может одним запросом выборка быть из разных частей таблицы с самого начало до самого конца.

[Виталий]

А я вот одно не понимаю, если есть ключ поиска ид и только ид, то о каких иных путях идет речь?

[alexdora]

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

[Виталий]

alexdora: ключей - то можно добавить тонну, только вот какой от этого смысл, если у вас идет выборка по айди? Может стоит пойти по другому пути? Отлавливать долгие запросы и работать над ними конкретно?