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

Разобрался в чём беда. Вот прям вообще не подумал бы. Расскажу детальнее. В 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. Впрочем, ситуация такая крайне редка.

Насколько безопасно пользоваться такими инструментами при разработке софта?

На 42.

Какие меры предосторожности есть?

Шапочка из фольги.

Анализируют ли подобные инструменты код проекта

А зачем бы они тогда были нужны, если бы не анализировали? При этом какие-то могут и не анализировать для упрощения собственной жизни или из-за внешних ограничений. Сейчас столько их развелось, что наверняка сказать нельзя. Про каждый инструмент написано на его сайте.

могут ли "стянуть" креды которые описаны в local.env к примеру

Могут. Но заниматься этим специально никто не будет из крупных специализированных компаний. Вдобавок, в local.env у вас и не должно быть каких-то реальных продовых токенов.

Ну и в общем интересуют мысли комрадов на тему кодогенерации.

Камрад пишется через "а".
AI-ассистентов нужно выдавать только опытным разработчикам, потому что они не пишут код, а уменьшают рутину. Их нельзя использовать, если вы не можете написать то же самое самостоятельно - помимо галлюцинаций там могут быть просто ошибки и разработчик должен быть способен распознать и то, и другое.
Судя по ответам тех, кто решает нафармить себе зачем-то рейтинга здесь, перезадавая вопросы ChatGPT, а так же по вопросам тех, кто не поленился, прежде чем придти сюда, сходить в тот же ChatGPT - это редкий навык.

Дружище! Нет «правильных» архитектур когда дело касается игр) Я думаю, идеально - разрабатывать под свои задачи сервер) Развивать, выстраивать свою архитектуру)

Это уже с позиции опыта в разработке. Мы с командой в какой-то момент нашли свой подход к решению тех или иных задач и уже какое-то количество времени его придерживаемся.

Из того чем я вдохновлялся в последнее время - даю ссылочку. Там целая серия статей. Не на Go но думаю стащить оттуда полезной инфы получится не мало
ТЫК

Похоже кто-то из китайцев обрезал планку ddr и продаёт её как ssd

Сначала n=2, затем n=0, потом снова n=2

Рекурсивные функции лучше визуализировать в виде дерева вызовов. В данном случае, это будет бинарное дерево, т.к. 1 функция (F(n)) может вызвать максимум 2 подфункции (F(n - 1) и F(n -2)).
Теперь самое интересное - представление в отладчике.
Вспомни, что функция заканчивается return F(n -1) + F(n - 2). Ответ на твой вопрос кроется здесь.
На самом деле эта конструкция разворачивается в нечто подобное:

int prev = F(n - 1);
int prevPrev = F(n - 2);
return prev + prevPrev;

На словах:
1. Ты вызываешь корневой F(2) - n = 2
2. Дебагер заходит в функцию и опускается до return F(n - 1) + F(n - 2)
3. Заходит в F(n - 1) - n = 1
4. Эта функция возвращает 1 - ты снова в родительской функции n = 2
5. Заходит в F(n - 2) - n = 0
6. Эта функция возвращает 1 - ты снова в родительской функции n = 2
7. Родительская (исходная) функция возвращает сумму - 1 + 1