Помогите с запросом к большой базе MySQL

[Black Hat]

где зачастую всё достаточно хорошо спроектировано

Либо проект маленький, либо везение у вас какое-то на такую хорошую архитектуру, либо лукавите.
Мне, если честно, не верится в такие сказки. Вы профилирование запросов перконой на сайте под нагрузкой проводили? Если это открытый движок, можете сказать какой?

 

[Роман Дмитриев]

Либо проект маленький, либо везение у вас какое-то на такую хорошую архитектуру, либо лукавите.
Мне, если честно, не верится в такие сказки. Вы профилирование запросов перконой на сайте под нагрузкой проводили? Если это открытый движок, можете сказать какой?

В сфере, где работаю, БД в редких случаях используется для веб-сайтов. Для заказчиков MySQL сейчас только на паре старых проектов остался. При этом есть вероятность, что его в ближайший год заменят на Elastic и Postgres.
Я писал не конкретно о том, что перевод дат в целочисленный формат даёт прирост в 60-70%, а о том, что на различных мелочах получается достичь прироста до 60-70%.
Зачастую это и получается после долгосрочного анализа запросов к БД и профилирования.

 

[Black Hat]

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

Все-таки по этой колонке будет индекс, который будет использоваться, и от преобразования выигрыша не будет. А вот неудобств - масса.
1. Забыли что TIMESTAMP/INT ведет отсчет от 1970 года - получили глюк , ведь есть люди до 1970 г.
2. Ок, пусть INT будет от 1900 года условно, т.е. смещаем нижнюю границу на 70 лет вниз. Тогда верхнее ограничение 2038 -> 1968 год
3. Ок, в дате рождения часы/секунды/минуты не важны, давайте за счет них "расширим" диапазон. В итоге получим "свой внутренний" тип, который будем писать как INT.
Вот в таком случае, да, будет INT! Но какими усилиями...