Vitaly Karasik

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

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

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

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

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

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

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

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

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

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

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

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

===

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

Любой сайт фриланса. Там за денюшку Вам составят подробный план и проект)
Насчет технических моментов - это не Ваша проблема, а реализатора

Разница в бинарях - Python на хостовой машине собран без отладочной информации, а тот, который в образе python:3.10.4 собран с нею.

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

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

PS
Никогда не используй образы Alpine - там вместо glibc суррогат под названием musl. В прочем для статически слинкованных бинарей на Go использовать можно, но тогда уж выгоднее использовать scratch

Я за семь минут сформулировал три разных ответа. Это ж надо так умудриться задать вопрос, что хрен поможешь.

(я использую MAMP) без него, вместо желаемого результата на странице появляется весь код PHP,

Ну. конечно будет появляться исходный код, ибо интерпретатора нет и никто исходники не обрабатывает.

когда подключается PHP код выходит ошибка (не находит страницу)

Ошибки - это нормально! Нужно найти причину и устранить ее.

Правильно заданый вопрос - 50% ответа. Тренируйтесь излагать мысли - полезно для кодинга

Можно указывать в названии PR:

feature/front/books-added-author-field
feature/back/books-added-author-field

Нужно/не нужно - скорее организационный вопрос. Если проект большой и народу много, то тогда вообще репозиторий следует делить на более маленькие для разных команд разработчиков, а не держать все в одной куче. Если же один-два - то вообще не принципиально.

DNS тут ни при чём, nginx это веб-сервер.

Если я правильно вас понял, вам нужно стандартное обратное проксирование сайта, описанное примерно в любой инструкции, например.

Посмотри установлен ли bash completion?

bashrc

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

На сайте используется TLS Fingerprint (вероятно, JA3) как один из индикаторов сессии в системе перед веб-сервером, вероятно, это анти-DDoS.
Так как браузер и curl используют разные SSL-библиотеки и передают разные наборы шифров, сервер предлагает вам пройти challenge.