Александр Аксентьев

Причем здесь группировка-то вообще?

Сортируйте по двум полям.

А в чем сакральный смысл выбирать сначала айдишники с LIMIT OFFSET, а потом делать второй запрос через IN?

Почему нормально не выбирать через лимит полные данные?

Лучше чем отдельный сервер в виде Sphinx или Elasticsearch ничего не придумали еще.

Но последние версии Mysql поддерживают полнотекстовый поиск.

Последние лет за 10? Он там уже плесенью покрыться успел.
"Недавно" только добавили поддержку для InnoDB в 5.6, и это недавно было в 2012 году.

не все числа складываются

Потому что для таких вещей надо как минимум делать
не так
update set field = newvalue

а вот так
update set field = field + newvalue

И скорее всего проблема будет решена.
По крайней мере информации достаточно чтобы предположить только такое решение.

с нормальной датой работать удобнее и быстрее чем с таймштампом цифрой.
По скорости на моих тестах datetime с индексом против int с индексом, выигрывал первый вариант. Хотя было очевидно что второй должен быть быстрее, оказалось что нет. (В Mysql базе естественно, за другие не скажу).

https://en.wikipedia.org/wiki/Entity%E2%80%93attri...
https://en.wikipedia.org/wiki/Faceted_search

Что значит вручную? Почему при создании записи нельзя проверить наличие адреса в справочнике и если его нет, то создать сразу же?

Самый нормальный вариант сделать таблицу и записывать отдельно строки.
А то будет коллекция костылей со временем.

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

Оно же где-то сейчас стоит, вы видите нагрузку. munin, htop, какое железо у вас знаете.

От этого и отталкивайтесь.

64гб на 30 гигабайтную базу это оверкилл.
Она все равно не висит вся в оперативке. Даже если бы вся висела это овердохуя.

Никто вам про вашу базу и сервер ничего не расскажет.

to_res_id индекс значит сюда нужен.

20млн записей в сутки

сразу прям в первый день, только домен купили и сразу 20 лямов набежало.

Без подготовки и фейлов ака опыта ничего не выйдёт, сначала надо смотреть сколько вообще нагрузки будет.
А нагрузка зависит от того что и как там будет работать.
А здесь никто будущее не предсказывает.

К тому времени когда будет 20 лямов реальных событий в день, у вас уже будет достаточно скилла чтобы это обработать.
Это 230 инсертов в базу в секунду, если писать в одну таблицу. И это для mysql-сервера из коробки овердохуя.
Неговоря уже про нагрузку на сам вебсервер и сервер в целом.
Т.е. это не работа для одного дедика 100%.

В общем всё это опытным путём в ваших конкретных обстоятельствах узнаётся.

создайте разные и проверьте какой вариант лучше через explain.

я бы вообще не стал order засовывать в индекс.
Если данных очень много, то отдельный индекс на поле которое будет в order by.
Либо только для where индексы и достаточно.

В целом проще проверить как быстрее отработает.
Создавать на все комбинации точно замедлит выборку и раздует таблицу.

лучше последнюю, всегда лучше.

"Duplicate entry 'pbkdf2:sha256:50000$' for key 'user_password'")

уникальный ключ на поле с паролем? Это гениально :D

просто сгрупируйте и по дате отсортируйте(уже у вас в запросе сортировка стоит)
в выборке с группировкой будет показана самая крайняя дата с учетом сортировки.

Может быть не надо делать это строкой? Кавычки зачем?