Adamos

Уличная магия с полным ее... в общем, полным.
У ТП хостера наконец дошли руки до моего тикета... и вдруг все заработало.
Тот же самый запрос выполняется, как положено, за миллисекунды.
В тех переменных, которые можно увидеть по SHOW VARIABLES, никаких изменений не произошло.
Единственная зацепка насчет причин - на старом сервере был MySQL 5.6, на новом - 5.7.
Впрочем, на сервере разработки у меня вообще MariaDB 8, и оно ему ни разу не мешало.

Спасибо за участие, джентльмены. Это было что-то выше нас ;)

P.S. График нагрузки у хостера через неделю. Явно видно, что конкретные запросы были ни при чем...

Порядковый номер, небось, еще и сбрасываться должен каждый год?
Например, можно сделать два запроса: INSERT, при котором id таки назначится нормальным авто-инкрементом, и UPDATE, который заполнит отдельное поле number значением

SELECT count(id) + 1 
  FROM orders 
  WHERE id < :currentId AND project_id = 2 AND created_at >= '2022-01-01'

Никакие гонки это не запутают.
А если этот number нужен только в одном месте, его можно таким запросом получать динамически и не хранить нигде вообще.

Не экономьте на спичках и просто храните все варианты записей.
А отображайте - ту, у которой стоит пометка "активная" (это последняя отмодерированная).

SELECT * FROM nano_user 
WHERE id IN (SELECT DISTINCT incoming_msg_id FROM messages) 
OR id IN (SELECT DISTINCT outgoing_msg_id FROM messages)
ORDER BY id DESC

Запрос, разумеется, не самый оптимальный.
Но судя по вопросу - и записей там далеко не миллионы, так что в обозримом будущем этот будет работать и не станет "бутылочным горлышком". Особенно если на идентификаторах в таблице messages проставлены индексы (а они, очевидно, должны быть проставлены, поскольку постоянно идет выборка для конкретного пользователя).

Вам открылась прекрасная возможность слезть с копролитов (Access) и прекратить бардак (копание пользователей в сырых данных без всяких ограничений).
Можно начать работать не с записями и таблицами, а с данными.
Нужно только разобраться, какие у вас данные, как с ними работают, и настрогать соответствующий интерфейс поверх любых популярных backend/frontend фреймворков.
Это не так страшно, на самом деле. Зато потом у вас будет инструмент для работы и новые горизонты понимания, как можно работать, если оторваться от мс-офисных привычек. Нормальные роли и рабочие процессы пользователей, нормальная аналитика для начальства, нормальное хранение данных, наконец, которому не страшен "первый же залетевший дятел"...

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

PMA тут вообще никаким боком.
Поведение зависит от драйвера БД - работающий напрямую с базой будет возвращать значения соответственно полям таблицы, а обертка - превращать все, кроме NULL, в строки.
Лучше не полагаться на то или иное поведение и либо приводить значения принудительно перед использованием, либо прописать эти поля как integer в модели, работающей с этой таблицей.

NULL - это не пустое поле. Это "поле не заполнено".
Используется в тех случаях, когда разница между этими состояниями - есть.
Кроме того, у числовых полей или дат просто нет "пустого" варианта.
0 и '1970-01-01 0:00:00' - это значения, которые вполне могут иметь смысл.
Например, при подсчете средних значений или интервалов NULL позволяет исключить ненужные строки.

Если вам без разницы, заполнил юзер свои поля или нет - значение по умолчанию подходит, использовать NULL просто незачем.

MS Server работает? Для текущей задачи не нужен? Ну и не трогай его.
Для LAMP действительно подойдет практически любой старый системник, и там ты можешь ставить-экспериментировать-переустанавливать-перезагружать что угодно, не трогая прочую инфраструктуру. Это же прекрасно...
Но поскольку ту базу и тот интерфейс нужно сначала создать, подними Докер на своей рабочей машине и делай все в нем. Чтобы потом просто аккуратно перенести файлы на сервер, а при необходимости - продолжать разработку, не ломая текущей работы.

Имхо, главный вопрос к этому ТЗ - на кой хер хранить PDF, который генерируется из картинки и текста, если его можно просто сгенерировать на лету из этой картинки и этого текста? Кейсы использования PDF обычно не подразумевают частого обращения, а вот заваливать генерированным контентом базу - довольно очевидная дурь.

Я бы взялся примерно так.
1. Сделал копию старой базы, чтобы спокойно баловаться и ничего не испортить.
2. Выгрузил дамп (только структуру) из старой и новой баз.
3. Открыл эти дампы в каком-нибудь Meld для визуального сравнения и начал:
- удалять те таблицы из копии, которых нет в новой базе;
- писать ALTER TABLE для тех мест, где структуры не совпадают.
И таким образом пришел на копии старой базы к тому, что должно быть в новой.
Если записывать каждый DROP / ALTER TABLE - получится повторяемый скрипт миграции.