Алексей Лебедев

Like вообще беда, нормально индексе работают только example.ru%
Можно попробовать поиграться с кодировкой поле к которому применяется Like.
Убрать регистрозависимость. То есть использовать в поле и в поиске только строчные буквы.
У нас был MS SQL и это положительно повлияло на LIKE %example.ru%

Для начала такой вопрос. Какой тип поля в БД и что делаем в запросе? Ищем вхождения, либо равные?

База 500ГБ плохо, плохо когда она не помещается в ОЗУ. Может ее стоить разбить на несколько баз или почистить?
Я уверен, что 99% данных можно хранить в текстовом файле без БД.

Я не могу понять как грязные данные и блокировки сочетаются?

Делаем UPDATE, если возвращает 0 затронутых строк, то делаем INSERT

Где нужно такие запросы делать?

Тут проблема в архитектуре.
Одно дело если редко, а вот другое дело, если постоянно.

В чем проблема?
1) получаем статус клиента. Список пользователей не надо получать, нужно лишь проверить на наличие в подписках и друзьях одного клиента.
2) получаем список альбомов.

Конечно первый вариант. Базы ж не пересекаются, а для внесения правок напишите скрипты. Это гораздо будет дешевле, чем разбивать.

А вообще, что для вас Higload. 20 млн строк - это мелочевка. Помню я скорость тестировал на 1 млрд строк.

Нужны следующие данные:
1) размер строки
2) что чаще чтение или запись
3) какая допустимая скорость ответа
4) количество одновременных запросов
5) типы запросов

Сделайте дату в UnixTime, либо сделайте свою систему отчета, допустим количество дней после 01.01.2015.
Может так уложитесь в 2 байта)

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

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

Ну а вообще задание тупое.

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