mayton2019

Все int я индексировал

Вот ты чудак. Надо не все индексировать а только те которые оптимизатор запросов может выбрать в плане запроса.
Ты кстати еще получишь обратную связь в виде замедления update/insert/delete на такой чудо-таблице.
Оптимизация - это искусство. И тут нельзя так... приходить и ВСЁ индексировать...

Обычно эволюция кода идет синхронно с обновлением схем в БД. Для этого есть инструменты типа liquibase/flyway. Они приводят в БД в состояние полного синхронизма с вашим репозитарием кода. И то что у вас происходит (нет таблицы) - это ужас-ужас и надо срочно что-то менять в жизни.

Вот так. Развивайтесь. Взрослейте. Хватит уже бегать в детских штанишках. Хорошая система должна трекать свои изменния. Берите лучшие практики которые есть сегодня. Создание таблицы в секции catch - это опасная практика которая кроме того вызывает еще один парадоксальный вопрос из серии - а что делать если exception возник внутри секции exception и так далее.

Скорее всего тебе придется ходить по всем колонкам и делать alter table ... change|modify ...

Вот так.

START TRANSACTION;
 INSERT INTO tab1 ....;
 INSERT INTO tab2 ....;
COMMIT;

И с точки зрения стороннего наблюдателя таблицы вставились "сразу".

Два действия полностью противоречат друг другу.

Оптимизирую сайт по скорости загрузки

Добавляем индекс по полю publication

Во время интенсивной загрузки индексы и триггеры и констрейнты мешают. Их выключают обычно.

Вообще чтоб дальше продолжать обсуждать - надо задать много вопросов. Что вы делаете вообще? Вы 1 раз загружаете или каждый день будете загружать?

Это одноразовый запрос
SELECT COUNT(*)
или будете каждый день его дёргать?

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

Если в нерабочее время - то можно было-бы убивать тестовую базу ночью. Копировать все датафайлы продуктовой. И стартовать ее снова. Ну там.. внеся какие-то косметические изменения в конфиг если надо.

Это самый быстрый способ IMHO. Но я его использовал под Oracle. Как будет комфортно для MySQL - чорт его знает.

Перетащил это всё на MongoDB с такой структурой:

Справочники остались в MySQL.
.......
Какие есть идеи?

Думаю попробовать перенести структуру на PostgreSQL аналогично MongoDB и использовать

Дружище. Так жеж не делается в мире Документно-ориентированных БД! В монге ты делаешь не таблицы. А хранилища документов. Где каждый документ - самодостаточен и полностью хранит в себе всю информацию. Грубо говоря никаких СПРАВОЧНИКОВ и СВЯЗНЫХ таблиц у тебя быть не должно. И нельзя джойнить документы. И нельзя джойнить документы с таблицами MySQL.

Почитай про модель АГРЕГАТОВ в противовес реляционной модели. Это можно найти в книжках типа NoSQL и еще я находил это в доках по Cassandra.

Для мультипоточных систем самый лучший дизайн concurrency - это уменьшение concurrency. Есть разные способы уменьшения этого. Простое правило - это хеширование. Вычисляем хеш от урла. И берем остаток от деления на количество workers. Число в результате - сообщит нам номер воркера который будет эти линки обрабатывать. Другие воркеры будут чужие линки игнорировать.

раскидал запись в каждую таблицу по функциям

Подобного рода рефакторинги надо сопровождать кодом. Наиболее вероятный вариант - ты создаешь отдельный connection в каждой функции. Так делать не надо. Второй вариант - ты играешся с коллекциями там где нужны курсоры. Третий вариант - транзакции и блокировки но все это надо смотреть в твой код.

Не мучай пожалуйста нас эпистолярным жанром. Давай код в студию едрён-батон...

Смотри. Обычно реляционная алгебра рассматривает коллекции внутри ячеек как потенциальную проблему. Проблему денормализации. Если скин у тебя это сложный объект с другими свойствами и эти свойства вдруг (!) внезапно обрастают связями с другими сущностями БД - то тогда считается что БД плохо спроектирована. Невозможно отслеживать целостность. Или представь что какой-то скин ты решил удалить из системы. Тебе придется сделать поиск всех коллекций всех плееров и поискать его и удалить. И те-же проблемы с вставкой и обновлением.

Но если ты никогда этого не будешь делать и тебе плевать на реляционные связи от скинов к другим элементам системы - то тогда можешь хранить в JSON. MySQL его поддерживает в угоду современным трендами на NoSQL.

Хотя тема NoSQL - гораздо более обширная и сложная чем просто денормализация. Про нее можно говорить часами.

Нужно материализовать ответы. И класть их на быстрое хранилище рядом с кешом типа nginx.

Тюнинг БД это процесс бесконечный и интересный. Вот еще брат-близнец (или сестра) под названием Мария тоже имеет двигатель для memory https://mariadb.com/kb/en/memory-storage-engine/

Есть там нюанс связанный с кнопкой Power. Так что будьте готовы к тому что это место - временное. Для кешей подходит разве что. Какую-то ценную информацию о финансовых транзакциях туда кидать нельзя.

Еще если БД стоит на отдельном хосте - то какую-бы быстроту вы ни выжимали из таблицы - перед ней стоит сетевой стек который вносит свои законные милисекунды. Имейте это в виду.

Вообще такая задача лучше ложится на структуры данных самого приложения. Поэтому - комменарий Дмитрия выше. Это звоночек о том что вы что-то не то делаете.

В программировании различают понятие стабильная сортировка (stable sort) когда подряд идущие одинаковые ключи в массиве при сортировке также идут в той-же последвательности со значениями. Но это работает только для массивов.

Реляционная алгебра не определяет никаких массивов. Собственно мы не знаем порядка как хранятся кортежи в таблице. Более того. Оптимизация пространства в БД может их тасовать как колоду карт. Тот-же вакуум в Постгресе. Или работа пакетов DBMS_SPACE для Oracle. Или любое delete+insert может сломать порядок который был раньше.

Поэтому применительно к БД такой вопрос лишен смысла. Если вам нужен какой-то дополнительный ранг сортировки - вводите новое поле (sequence_num) и сортируйте по field,sequence_num. Тогда будет порядок.

Все бесплатные UI инструменты поражают своей убогостью. Мне после Toad/SQLDeveloper кажется что разработчики Windows-приложений просто разучились делать классические оконные апликухи. DBeaver - видел. Но на нем есть след толи Swing/AWT толи SWT со всеми вытекающими. Чувсвтуется что не родной.

Автор если у тебя установлен mysql клиент - то можешь использовать консоль mysql. Бонусом будет то что научишся хорошей практике.

Вот как-то так она выглядит.

$ mysql --help
mysql  Ver 15.1 Distrib 10.3.34-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Usage: mysql [OPTIONS] [database]

Там и базы можно посмотреть и таблицы.

Такие задачи я делал просто в текстовых редакторах. Надо только найти тот который загрузит файл на 1.4Гб.
Попробуй Notepad++. Потом визуально можно просто отметить номера строк для резки. И уже порезать консольными утилитами типа head/tail

Если вообще не осилил - тогда качай докер. Потом mySQL https://hub.docker.com/_/mysql Ну и дальше погнал. Загружай.