Есть такая проблема, что таблица разрослась до 1,5 млн записей. И теперь запросы к ней грузят процессор под 100% и саму mysql.
Есть такой запрос, который я выполняю каждый раз (ВСЕГДА) прежде чем сохранить что-то в эту таблицу: мне нужно узнать есть ли запись уже в таблице и сравниваю я по 1 или 2 колонкам. И ищу по длинному ID из цифр 20 в колонке service_id. Запросы происходят порой по 10 в секунду примерно - это пока что пик, но будет больше.
Как можно оптимизировать? Внедрить индексы, но насколько их хватит? Как быть если в месяц будет прибавляться по 1 млн записей в этой таблице, что нужно использовать при таких объёмах?
UPD:
есть такой индекс, чтобы при добавлении записи она была точно уникальна:
messages_account_id_service_id_channel_unique - 3 колонки - accound_id, service_id, channel
Такие поля id, text, ..., accound_id, service_id, channel - это примерно. Всего 20 полей.
< Выборку делаю по channel и service_id.
Если выборка всегда только по этим двум полям, то вам нужно сделать составной индекс конкретно по этим двум полям.
< messages_account_id_service_id_channel_unique - 3 колонки - accound_id, service_id, channel
Этот индекс сработает только если в условии выборки участвуют все три поля.
1) сначала проверьте, что нужные индексы подключаются к запросу. Изучите запрос EXPLAIN.
2) если нужных индексов нет, постройте их.
3) попробуйте нормализовать базу. Например, у нас в запросе участвуют всегда три колонки и куча остальных параметров. Отделите эти три параметра в отдельную колонку и один дополнительный ID. Вставку делайте двумя запросами, в транзакции, сначала параметры в одну таблицу, потом три колонки и получившийся ID в другую.
4) если данных все равно много, то разбивайте таблицы на партий и по какому-то признаку, например по хешу.
Средний
