Алексей Уколов, ну теоритически, можно было бы действительно добавить еще одно поле, например, is_alive, которое по умолчанию = 1, а после удаления становится null, и повесить уникальный индекс alias + is_alive. Тогда "живая" запись всегда была бы гарантировано одна, а "удаленных" сколько угодно.
Сергей Горностаев, Вы хотите сравнить откуда лучше и качественнее получить исчерпывающую информацию по технологии/ящыку. Но мне не нужна исчерпывающая информация.
С видео-уроков проще начать, а потом, когда уже ясна общая картина, можно идти и читать более что-то более подробное.
Для меня, как и для многих других, и вы не можете с этим спорить, удобен процесс освоения технологии такой:
1) Поверхностно ознакомиться, желательно максимально общирно. С аналогиями из других технологий, если это возможно
2) Попробовать самому. Когда общая картина ясна, я могу самостоятельно попробовать что-нибудь написать.
3) Идти и читать официальную литературу.
Даже форматы у тех же видео бывают разные. Есть длинные и подробные, по нескольку часов, а есть поверхностные, а-ля "Go за 30 минут". Да, они никуда не годятся с точки зрения полноты информации, но за то я могу за 30 минут понять о чем вообще идет речь и как это работает, а потом углубляться.
Сергей Горностаев, Неправда. Все люди разные, кому-то удобнее читать, кому-то смотреть. Все индивидуально.
Сеньорами не становятся, прочитав книгу или посмотрев видео-урок. Нужно много практики и опыта. Книга или уроки - это для ознакомления.
Я именно про основы говорю.
Вопрос не о сборке самого билда, а о "рендеринге", которым и занимается nuxt на сервере. Тесты проводим через AB, запросы к АПИ тестируем отдельно. То есть в тесте только отдача "отрендеренной" страницы. Так что MySQL тут не при чем. Во время теста идет загрузка процессора nodejs.
Все верно, но я никогда не видел такой рекомендации ни в одной статье по MySQL. Такая ситуация ведь везде встречается. Мы создаем индекс на два поля, но вдруг, нам нужно выбрать еще и по третьему.
Просто добавляем третье поле в условие и получаем профит? Очень неожиданно, поэтому я решил не поверить explain и спросить.
Алексей Уколов, Основная задача - статистика для каждого пользователя. Тут все идеально. Статистика для всех - это только для администратора, ее я вообще кэширую. Но тем не менее, добавление условия user_id > 0 почему-то показывает лучший результат, чем его отсутстие. Это меня смутило.
Иван, Точнее created_at может и лучше, чем user_id > 0, но ведь в остальных случаях, когда у меня конкретный user_id, мой индекс эффективнее. То есть вы предлагаете переделать индекс ради общей аналитики и ухудшить аналитику для каждого отдельного пользователя?
Иван, Думаю, что не ограничивает, ведь под нужный created_at подходит статистика и других пользователей, а user_id сразу отсекает статистику только для текущего.
