Vindicar

Сначала создай курсор, потом на нём уже вызывай execute() для выполнения запросов. Когда закончишь работать с курсором - вызови close(). Это часть спецификации DB-API 2.0, которому следует большинство библиотек для работы с БД на питоне.

Потому что ты выполняешь два запроса INSERT. Запрос INSERT добавляет новую строку. Всё логично.
Тебе нужно сделать одно из двух:
Вариант 1. Изменить код так, чтобы бот накапливал сведения в памяти, и только на самом последнем этапе заносить собранное в БД. Я вижу, ты используешь FSM - отлично! Этот механизм позволяет хранить произвольные данные в контексте состояния.
Вариант 2. Сделать, как сделал Pasha выше - вносишь первую порцию данных через INSERT, остальные - через UPDATE. Тогда у тебя на последующих этапах будут обновляться существующая строка.
Можно сделать, как предложил fenrir - использовать UPSERT, который сводится к "если строки нет, делай INSERT, если есть, делай UPDATE", но я бы не советовал его тут использовать - лучше сначала чётко разобраться, что и как работает.

Разница между вариантами будет в ситуации, когда бот отвалился в процессе регистрации. В первом случае собранные частичные данные будут забыты, и пользователю придётся регаться с начала. Во втором случае у тебя в базе будет недореганный пользователь, что может "всплыть" (спровоцировать ошибки) в дальнейшем. Так что я бы предпочёл вариант 1.

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

Какое лютое извращение.

user_parsing_ok = cur.fetchall()
    korteg = ()
    for k in user_parsing_ok:
        korteg += k
        step += 1

Во-первых, вы вытаскиваете 3 миллиона записей в память как питоновские объекты. Это не очень хорошая идея.
Во-вторых, вместо того, чтобы по-человечески сделать

korteg = tuple(item[0] for item in user_parsing_ok)

вы делаете конкатенацию кортежей по одному. Напомню, что при конкатенации создаётся новый кортеж - так что при добавлении трёхмиллионного элемента у вас в памяти будет один кортеж с 2999999 элементами и один кортеж с 3000000 элементами. Это дело будет люто, бешено, неиллюзорно жрать память, а значит, свопиться на диск. Что не прибавит скорости.
Как написали выше, просто используйте подзапрос. Вам совершенно незачем таскать эти айдишники из БД в питон, а потом из питона в БД. Пусть они обрабатываются только в рамках БД.

Если бот находится на этом сервере, то просто запрашиваешь канал через bot.get_channel() и потому уже проверяешь channel.guild.id на полученном канале.
Если бота на сервере нет, то я без понятия, возможно ли получить информацию о сервере. Я бы предположил что нет.

заглавные буквы идут в кодовых таблицах подряд. По идее, будет достаточно что-то типа:
WHERE substr(word, 1, 1) BETWEEN 'A' AND 'Z'
если таблица word меняется нечасто, добавь в неё отдельный столбец, содержащий первую букву, и сделай индекс по нему. Может значительно ускорить дело.

Ты эту БД давно используешь? Просто новички часто споыткаются о простой факт. Запросы вида CREATE TABLE IF NOT EXISTS создадут отсутствующую таблицу, но не изменят таблицу, если она уже существует. Даже если структура таблицы отличается от заданной. Скажем, если ты добавил автоинкремент в запрос CREATE позднее, то в реальной таблице его не будет.
В таком случае проще всего снести файл базы, чтобы она пересоздалась, и снова наполнить его данными.

Также можешь попробовать узнать реальную структуру твоей таблицы так:

SELECT sql FROM sqlite_schema WHERE type = 'table' AND name = 'customers'

Ты просто не понимаешь сути первичного ключа.
Это значение, которое однозначно идентифицирует строку, независимо от наличия и количества других строк в таблице. И точка. Он не должен меняться вообще за время жизни строки.
Бывают случаи, когда у нас уже есть уникальное значение, которое можно использовать как ключ.
Но куда чаще используются синтетические ключи, т.е. просто числа, которые пользователь по-хорошему и видеть-то не должен никогда. А раз так, то какая разница, есть ли дырки в нумерации?
Я больше скажу, иногда сплошная нумерация - это слабое место в системе.

Дополню ответ Сергей Горностаев

cursor2.execute("SELECT sneakers_model FROM user_inventory WHERE sneakers_model = ?", (random_sneakers[0]))

А надо

cursor2.execute("SELECT sneakers_model FROM user_inventory WHERE sneakers_model = ?", (random_sneakers[0],))

Без запятой у тебя просто строка передаётся, и поэтому функция каждый символ считает за отдельное значение. Вот и получается 17 символов в строке = 17 значений, а место одно.
С запятой ты передаёшь кортеж из одной строки. Одна строка - одно место.

Путь к файлу у тебя относительный, т.е. он будет зависеть от текущего рабочего каталога. А тот, в свою очередь, зависит от того, как ты запускаешь скрипт, и может меняться в ходе работы скрипта.
Так что если нужен путь именно относительно скрипта, используй pathlib.

from pathlib import Path
from sys import argv

script_dir = Path(argv[0]).parent.resolve()  # путь к каталогу скрипта
db_path = script_dir / 'basa' / 'users.db'  # путь к файлу в подкаталоге

Category ID пробелы в именах столбцов - не лучшая идея. У тебя точно толбец так называется? Если да, то оберни имя столбца в `бэктики` (обычно на клавише Ё).
Ну и да, сдаётся мне, что 'call.data' не будет работать так, как ты это ожидаешь.

@dp.callback_query_handler(text='1')
async def id1(callback: CallbackQuery):

Этот обработчик прикреплён к кнопкам в сообщении /start. Поэтому callback.message указывает именно на это сообщение.
А тебе нужно дождаться следующего сообщения. Читай про finite state machine.

SELECT user_id, join_date EXTRACT(DAY FROM date) as day FROM users VALUES (?, ?)

SELECT запросы c условием пишутся не так.

Запомни простую вещь: никогда, никогда не формируй SQL-запросы форматированием строк. Ни f-строками, ни методом format(), ни %-форматированием. Ты сейчас на своей шкуре почувствовал, почему этого не стоит делать.
И читай документаци, там написано как правильно. Более того, есть отдельный раздел как раз об этом. RTFM!