Владислав Лысков

SELECT DISTINCT city.name
FROM city
INNER JOIN ad_cars ON city.name = ad_cars.city
ORDER BY city.name;

INNER JOIN соединяет две таблицы на основании совпадения значений в столбцах city.name и ad_cars.city.
DISTINCT удаляет дублирующиеся записи.
ORDER BY city.name сортирует результаты по названию города.

Простой ответ: да, нужно.
Сложный ответ: не обязательно, можно компилировать шаблоны на лету подключив полный бандл vue на страницу, а потому с использованием костылей от сторонних разработчиков или самописных, возможно будет работать и с целыми компонентами, перекладывая вычисления на сторону пользователя. Но делать так не надо.

Надо брать на 16гб ОЗУ минимум, а лучше на 32.
Хорошо прям будет на 64.

Вот вкладка Memory в Activity на моем маке на м2про процессоре:

Это Идея, телега, меньше 10 вкладок в хроме.
Можно заметить, что 16Гб чуть-чуть не хватает для всего этого, так что использовался бы своп.

Он будет работать не намного лучше вашего текущего ноута, какой бы он не был. Брать дорогой мак только чтобы попробовать при отсутствии денег и реальной необходимости именно в маке - не самое разумное решение. Переход с винды на мак - болезненный процесс. Привычки и удобство использования рабочего инструмента тоже важны. В вашем случае лучше поднакопить еще немного и взять современный ноут/ПК на винде. В идеале - новый. Брать б/у - лотерея, надо будет проводить перед покупкой полную диагностику и проверку. Не игровой, наличие M2 SSD и как минимум 16 гигов ОЗУ обязательно (что-то примерно типа из этого списка). А если и брать мак - то как минимум эир м1 с 16 гигами оперативной памяти.

Да

Вернее sury.org заблокировал Россию

Пруф: https://github.com/oerdnj/deb.sury.org/issues/2155

Нет конечно, вы что хотите выйти на 1 место по слову портфолио , его в целом можно даже не индексировать, оно не для поиска оно для людей

Разобрался в чём беда. Вот прям вообще не подумал бы. Расскажу детальнее. В BIOS отображаются все HDD и SSD. Вынимая SATA определённого HDD - из биоса он пропадает, и после снова подключая в разъём, загружаемся и ву-а-ля всё работает и никаких out of memory. Что за бред, не знаю. Все 7 системников с такой проблемой были. Капец конечно) Но всем спасибо :3

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

1. Ваша должность называется "эникей"
2. Ваша з.п. - 25тр

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

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

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

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

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

Я рекомендую Gitlab
- Можно хостить весь Gitlab у себя. Вначале это может показаться лишним, но многие работодатели так делают, поэтому навыки по работе с Gitlab пригодятся.
- Отличный CI. Как по мне, гораздо лучше чем Github actions
- Проекты в Gitlab можно спокойно и очень просто синхронизировать с тем же самым Github прямо из интерфейса Gitlab, таким образом мы получаем преимущества обеих систем.

bitbucket всё, забудьте о нём.