Что можно сделать с таблицей в которой постоянно 700т записей и 300 запросов в секунду?

Например так

num_rows1 = SELECT * FROM таблица1 WHERE что то ишем 
num_rows2 = SELECT * FROM таблица2 WHERE что то ишем
num_rows3 = SELECT * FROM таблица3 WHERE что то ишем
num_rows4 = SELECT * FROM таблица4 WHERE что то ишем
num_rows5 = SELECT * FROM таблица5 WHERE что то ишем

if(num_rows1  == 0 AND num_rows2  == 0 AND num_rows3  == 0 AND num_rows4  == 0 AND num_rows5  == 0){
ничего не нашли
}

А при записи
INSERT таблица.rand(1,5)

По идее получится что будет 5 таблиц и в каждой чуть больше 150т записей.

Поможет ли это ?

Нет, Вы не поняли аналогии.

К примеру, у Вас там хранятся некие логи. У каждой записи лога можно выделить характеристику, например, тип записи лога ("new_message", "login", etc). И таблица `log` уже делится на `log_new_message`, `log_login`.
Либо если такой характеристики нет, то можно построить аналог DHT. У каждой записи лога есть, к примеру, пользователь, который сгенерировал эту запись. Посчитав хэш от его id и через XOR преобразования - можно выбрать одну из нескольких таблиц, в которую пойдет запись. Полностью это проблему не решит, а возможно, создаст перегрузку лишь одной таблицы, если пользователи (у которых хэш будет "ближе по DHT" к запрашиваемой таблицу) создают львиную долю запросов. Т.е. по факту я так понимаю вам нужно сделать некий "маршрутизатор" из запросов и каждый должен идти в соответсвующую таблицу. Чтобы не менять логику приложения сильно - то можно сделать view на эти несколько таблиц. Т.е. это уже более тонкая оптимизация.
Я бы все таки попробовал реализовать первый описанный метод, а DHT и прочее оставить на "десерт" и попробовать поиграть с ним в свободное время.

Владимир Скибин, Данные там однотипные их не разделить... Мне не понятно есть ли для бд разница. Читать 5 таблиц по 150т записей или читать одну на 750т записей ?

WiNNeR_tig, У Вас в раз идет чтение всех 750к записей? или EXPLAIN показывает, что запрос при обработке использует все 750к записей? Попробуйте переопределить запрос таким образом, чтобы "окно" обработки было более меньшим. Также в данном случае лучше не использовать SELECT *, а перечислить нужные поля, это даст небольшой прирост.

Владимир Скибин, там не нужно читать сами поля, нужно найти есть ли уже запись. Т.е. я делаю так

if($mysqli->query("SELECT `id` FROM `таблица` WHERE `поле` = 'номер который ишем' LIMIT 1 ")->num_rows > 0){ запись есть

WiNNeR_tig, А что EXPLAIN показывает на Ваш запрос?

WiNNeR_tig, как видно из скрина - у Вас используется только индекс по полю status, а далее каждая из 55170 строк сравнивается в "ручном" режиме. Попробуйте сделать составной индекс по полям (именно в этом порядке) `status`, `idad`. Что в этом случае покажет EXPLAIN ? Т.е. нужно добиться того, чтобы в key был нужный индекс и rows было минимальным. Также желательно, чтобы Extra вообще было пустым.

Владимир Скибин, А как поменять порядок индекса ?

WiNNeR_tig, лучше тогда пересоздать индекс.

ALTER TABLE `tb_visits` ADD INDEX `idx_status_idad` (`status`, `idad`);

При порядке важно понимать по какому критерию меньше "окно" запроса. Для этого можно посмотреть

SELECT `status`, count(*) FROM `tb_visits` GROUP BY `status`;
SELECT `idad`, count(*) FROM `tb_visits` GROUP BY `idad`;

Чем выше селективность (для выборки по ключу меньше значений) у запроса - тот индекс и надо ставить первым. Т.е. проще сначала выбрать 1000, а потом из этой 1000 выбрать 20, чем выбрать 50000, а потом из этих 50000 выбрать 20

Владимир Скибин, https://yadi.sk/i/fZ0ajp-i3N9TTE

WiNNeR_tig, А что теперь EXPLAIN показывает?

Владимир Скибин, переделал немного индексы и программу

https://yadi.sk/i/qH0vmWhM3N9bw8

https://yadi.sk/i/bzUn6tQw3N9c3D

WiNNeR_tig, EXPLAIN вместе с запросом обычно показывают )
А так у Вас получается что из 2-х возможных индексов мускул выбрал тот, по которому уже лучше делать выборку.
Долно получиться что то вроде такого: https://www.screencast.com/t/7fcjTkrazAbT

Владимир Скибин,

https://yadi.sk/i/sk5z4xuI3N9dKW

Но там несколько вариантов , такой чаше всего

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

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