Периодически на почту приходят письма от рекрутеров. Причем в 80% случаев это не прямой работодатель, а кадровое агентство. Предлагают рассмотреть позицию android-разработчика. Описание каждый раз примерно такое:
Работодатель:
Компания, занимающаяся разработкой сервисов (Ни название компании не указано, ни род деятельности)
Требования:
Стандартный скопированный набор java/kotlin, SDK, MV-что-то там
Обязанности:
Разработка android-приложения, взаимодействие с участниками процесса (Ничего себе, кто бы мог подумать? Естественно никакой информации о приложении, участниках и процессах нет)
Условия: Комфортный офис рядом с метро (не указано с каким), белая зп (вилки нет), молодой дружный коллектив
Попытки выяснить уточняющую информацию как правило ничего не дают.
Возможно за этим описанием и скрывается классная фирма с крутым приложением и командой, но желания даже просто ответить на такое сообщение у меня сейчас не возникает.
Про WHERE… IN (...) полностью поддерживаю. Скажу за MySQL. До версии 5.6 такие подзапросы в секции WHERE сервер вообще никак не оптимизировал. Позже была добавлена оптимизация простых подзапросов без JOIN'ов.
Так что лучше избегать подобных конструкций и выносить их в секцию с JOIN'ами как, например, показано в комментарии выше.
Мне вот очень нравится, как подобный функционал реализован в dbForge для работы с MySQL, частно им пользуюсь. Так что можете посмотреть для сравнения.
В вашей же программе радует количество поддерживаемых БД, довольно универсально получилось.
С версии 5.6 мускуль стал оптимизировать конструкции вида WHERE… IN (SELECT ..), но на подзапросы всё равно накладывается ряд ограничений. Подробнее можете почитать в мануале вот тут Optimizing Subqueries with Semi-Join Transformations
...
SELECT fp2.id
FROM forum_posts fp2
WHERE fp2.created >= '2013-01-01'
AND fp2.created < '2013-02-01'
GROUP BY DATE(fp2.created), fp2.user_id
...
Группируете по DATE(fp2.created), fp2.user_id, а выводите fp2.id. Обычно выводят либо поля, по которым группировка, либо другие, обернутые в агрегатные функции.
К сожалению сейчас даже такие задачи многих соискателей ставят в тупик. 50% кандидатов как правило можно завалить вообще простым заданием на применение обычного LEFT JOIN.
На information_schema.tables я бы на вашем месте опираться не стал, т.к., например, для InnoDB столбец TABLE_ROWS содержит лишь грубую оценку количества строк в таблице, а не точное значение.
Не забывайте, что функция RAND() — детерминированная, и соответственно в WHERE у вас каждый раз для каждой строки будет вычисляться новое число rand()*100000, так что про индексы тут можете смело забыть.
Люблю и по возможности читать бумажные книги, есть в этом какое-то свое удовольствие. Жаль только, что техническая литература всегда довольно объемна и нет возможности постоянно таскать с собой том на 1-2к страниц, так что в дороге в основном пользуюсь планшетом, а в процессе работы ноутбуком.
Может и скажу сейчас банальную фразу, но я считаю, что возраст в программировании не важен, главное, чтобы работа приносила удовольствие. А если уж начинаешь рассуждать так, как описано в статье, то возможно пришло время попробовать себя в чем-то другом?
Лучше уж сразу потратить время на разработку нормальной системы, чем понаписать непонятно что, а потом править и фиксить все косяки и убивать запросы при этом.
> первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Если вы собираетесь выявлять подобные проблемы в процессе эксплуатации, то думаю ваша система долго не протянет.
Работодатель:
Компания, занимающаяся разработкой сервисов (Ни название компании не указано, ни род деятельности)
Требования:
Стандартный скопированный набор java/kotlin, SDK, MV-что-то там
Обязанности:
Разработка android-приложения, взаимодействие с участниками процесса (Ничего себе, кто бы мог подумать? Естественно никакой информации о приложении, участниках и процессах нет)
Условия: Комфортный офис рядом с метро (не указано с каким), белая зп (вилки нет), молодой дружный коллектив
Попытки выяснить уточняющую информацию как правило ничего не дают.
Возможно за этим описанием и скрывается классная фирма с крутым приложением и командой, но желания даже просто ответить на такое сообщение у меня сейчас не возникает.
Так что лучше избегать подобных конструкций и выносить их в секцию с JOIN'ами как, например, показано в комментарии выше.
В вашей же программе радует количество поддерживаемых БД, довольно универсально получилось.
Группируете по DATE(fp2.created), fp2.user_id, а выводите fp2.id. Обычно выводят либо поля, по которым группировка, либо другие, обернутые в агрегатные функции.
Тогда уж (ID, A, B, C).
И на мой взгляд как-то многовато воды в статье. Хотелось бы больше примеров на реальных данных и с DDL таблиц.
> первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.
Если вы собираетесь выявлять подобные проблемы в процессе эксплуатации, то думаю ваша система долго не протянет.