deepblack

Поскольку файлы уже отслеживались и есть в git, недостаточно добавить их в .gitignore, помимо этого нужно удалить их из git

git rm --cached index.html

Если сайт хостится через GitHub Pages, то как раз index.html из репозитория и считывается для этого. Если удалить index.html, никакой сайт никто не увидит. Хотите сделать сайт с закрытым кодом - храните код в приватном репозитории и показывайте через платный хостинг.

Значит есть открытая сессия с этой БД. Закрой ее (например, pg_terminate_backend()) и повтори заново

https://www.ozon.ru/product/karta-adapter-ssu-msat...
А судя по описанию, с вашим компьютером в комплекте должны быть наборы для установки 2.5" SATA устройств.

Давайте по порядку. В документации дискорда очень четко прописаны лимиты для вебсокета и чуть менее четко для HTTP. Цитировать оттуда не буду, думаю там все понятно.

В общем виде ошибка 429 говорит, что в один из двух лимитов вы не укладываетесь. Чтобы не происходила ошибка можно перед выполнением действий проверять блокировку через AutoShardedClient.is_ws_ratelimited, но это не лечение проблемы, а только обработка.
Для лечения нужно перехватывать ошибку в глобальном обработчике и по стеку вызовов смотреть на каком действии она происходит. Если приложите стектрейс к запросу, можно будет по нему сказать конкретнее. Только убедитесь чтобы логи не обрезались как у вас выше. Может быть и так было бы понятно, но эндпоинт https://discord.com/api/v10/channels/1215300998588... весь не видно. Учитывайте что она может и в разных когах происходить об этом ниже.

В целом дискорд не любит, когда боты делают что-либо без явных действий пользователя. Причем чем больше бот, тем строже, поскольку для них это больше нагрузки. К примеру в коде, который вы приложили есть обновление статуса каждые 10 секунд. Будем объективны, пользователям плевать что у бота в статусе, но эти запросы так же идут в общий рейт лимит. Я бы советовал поставить или большое значение (5-10 минут) или вообще избавиться от этой карусели.
Аналогично пройдите по остальному коду, который не приложен и посмотрите есть ли периодические запросы без явных команд: например обновления каких-нибудь сообщений по таймерам. Если есть увеличивайте таймеры в 2 раза (повторять до исправления) или подумайте как предоставлять функционал без этого.

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

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

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

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

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

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

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

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

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

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

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

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

===

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

Чтобы сохранялся один раз нужно проверять:
:есть ли в файле такой id
:если есть то мы ничего не делаем или пишем: "Такой id уже зарегестрирован"
: если нет то вписываем

пример:

id = "id"

file = open("yourFile.txt", "r")
fileReaded = file.read()
file.close()

if id in fileReaded:
    print("Пользователь по етому id уже зарегестрирован!")
else:
    file = open("yourFile.txt", "a")
    file.write("id")
    file.close()

использовать SQlite (поддержка которого встроена в питон) + индексы навесить на ID пользователя