index0h

Запросы делались по одному, без оборачивания в транзакцию (насколько я понимаю, если запрос один - то и транзакция бесполезна, независимо от кол-ва строк?).

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

Кроме этого, batch-запросы с auto increment имеют намного меньшее max время вставки: 1,5 сек против 11,4 (да, 11 секунд на вставку 20 строк).

Верно, это вполне ожидаемый результат.

правильно ли я решаю эту проблему и действительно ли суррогатный ключ в таких ситуациях даёт прирост скорости?

Не совсем. Индекс не ускоряет вставку, что обычный, что комплексный, он ускоряет поиск. Чем меньше индекс - тем быстрее он рассчитается.
Очень похоже на то, что у вас проблема несколько иного характера. Индекс хранится в ОЗУ, тормоза на вставке вероятно у вас за счет того, что индекс не влазит в буфер движка. Это значит, что при вставке БД занимается вытеснением из буфера одних индексов другими, а это уже работа с файловой системой, что очень медленно.
В таких ситуациях стоит двигаться в сторону уменьшения размера самого индекса.

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

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

В большинстве случаев FK не нужны, от слова совсем.

Проще всего - решать конкретные задачи.

1. НИКОГДА не публикуйте креды к базе!
2. Не используйте подстановку данных в запрос через конкатенацию. Вместо этого используйте плейсхолдеры.
Пример 1 (SQL инъекция):

# Тут заэнкожено: '; DROP TABLE `users`; --
curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone=%27%3B%20DROP%20TABLE%20%60users%60%3B%20--'

Пример 2 (phone может содержать массив):

curl -XPOST -H 'Content-type: application/x-www-form-urlencoded' -d'phone[]=+123'

3. Не используйте глобальные переменные. Про это есть множество статтей.
4. Если есть возможность - используйте \PDO, вместо mysqli.
5. Не стоит объявлять функции/классы/трейты/интерфейсы по условию. Вместо этого используйте их по условию, но объявляйте без него.
6. При работе с путями рекомендую пользоваться глобальными, вместо относительных, иначе этот самый путь будет зависеть от скрипта, с которого запустили ваш код, а не от того, где происходит работа с файлами.
7. У вас конкурентно не безопасный код за счет того, что работа с файлами происходит в одном и том же каталоге, с одними и теми же именами файлов. Что будет если запустить два запроса одновременно на вытяжку всех пользователей? В лучшем случае один из запросов просто упадет с ошибкой что не может добавить в архив файл (это второй поток его уже удалил). Если будет запущено 2 запроса например на 1го пользователя и на всех - есть вероятность, что один из них вернет далеко не запрашиваемые данные)).
8. Очень рекомендую разделить вашу обработку на 2 части:
- Первая пусть записывает в файлики данные по пользователям при обновлении данных этих пользователей.
- Вторая - вытягивает вытягивает только id требуемых для архивирования и уже добавляет их в архив. Имя архива стоит делать рэндомным, что бы избежать конкурентного доступа к одному и тому же файлу на запись.
9. getUserses -> getUsers

Конкретно по вашей проблеме: если я праивльно понимаю, вы в один и тот же архив запихиваете файлы на каждый запрос, грубо говоря один раз вытянув всех пользователей - дальше вы только обновляете их в архиве на 10к файлов, а не создаете новый архив.

id int unsigned,
createdAt timestamp,
startedAt timestamp,
finishedAt timestamp,
interval int unsigned -- Я не очень понимаю, что у вас такое интервал, храните лучше в секундах.

По крону каждую минуту (можно и 10 мин, это не особо важно) вытягиваете записи, у которых startedAt >= CURRENT_TIMESTAMP() и finishedAt < CURRENT_TIMESTAMP(). Интервал и вот это вот все уже на части пыхи обрабатываете. Не забудьте комплексный ключ для startedAt+finishedAt добавить.

При выборке обязательно добавляйте погрешность, хотя бы секунд 5-10, либо вместо CURRENT_TIMESTAMP подставляйте округленное время, например для времени 10:20:01 используйте 10:20:00

Операция удаления - очень дорогая. Вам точно нужно именно удалять? Может лучше выводить 5 последних?

Зависит от движка MySQL, его настроек и запроса. Например обновление одного рядка в Innodb обычно блокирует только эту строку, в MyISAM блокируется вся таблица. В случае SELECT FOR UPDATE (Innodb) блокируются все выбранные строки до завершения транзакции. Операции со схемами, типа CRUD полей/ключей/констрейнтов/транкейт - блокируют таблицу полностью.
Более детально гуглите на тему: уровни изоляции транзакций mysql.

Вы забыли точку с запятой после

$result = $mysql->query("SELECT * FROM `users` WHERE `login` = `$login` and `pass` = `$pass`")

Используйте плейсхолдеры. Подход: `login` = `$login` ведет к SQL инъекциям