mayton2019

Первым делом надо доказать отсутсвие глупых ошибок. Типа вместо продуктовой БД пошел в тестовую.

Сделай этот-же запрос из mysql консоли

mysql> SELECT flag FROM designbase WHERE id = 501285409

И попробуй для 2 исходника включить автокоммит как тут пишут https://mariadb.com/kb/en/mysql_autocommit/

Обычно UNION автоматически делает distinct для всех таблиц-участников процесса union.
Это является причиной замедления.

Используй UNION ALL.

Если говорить о pet-проектах то нагрузка там маленькая. MySQL можно поднимать локально или в локальном докере.

Реальная потребность во внешнем хостинге обычно идет от реальных задач. Тоесть от задач которые приносят деньги. И поэтому обсуждать бесплатные хостинги с негарантированной полосой - нет смысла. Они все равно будут хуже чем платные. Это мой опыт работы с Amazon. Все бесплатное - нихрена не работает. Не поддерживается. А если ищете поддержки - начинайте платить.

Наверное не value а values

INSERT INTO books (title, author, price, quantity) values

Есть базы данных, весит примерно 40 гб. Нужно его восстановить на свой сервер

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

(я достигал резкого увеличения скорости загрузки когда переключал engine с InnoDb на MyISAM.
Это было давно. И как щас я не знаю. Может щас появились новые engines которые лучше чем
MyISAM. Надо читать. Но на тот момент мне транзакции были безразличны. Нужно было просто
хоть как-то загрузить данные и MyISAM помог).

Очень хорошо грузится CSV в пустую свеже-созданную таблицу без ничего. Даже не надо объявлять PK.. Лучше потом его активировать и также добавить констрейнты в режиме no check.

UPD:

Мне кажется что для обобщения надо все таки новую статью добавить в MySQL. Чтоб API проводящий сравнение хотя-бы был единообразным.

И наверное есть много способов решать эту задачу. Но она по своей природе близка к полно-текстовому поиску хотя-бы потому что слова и их комбинации могут отличаться. Могут быть переставлены местами. Могут быть с опечатками. С переносами в середине слова.

Насчет Sphinx - ничего не скажу. Не использовал. Но в классическом текстовом поиске все слова хешируются в 18-20 битные числа. Потом гистограмма. И дальше эти векторы можно быстро сравнивать. (там еще слова чистятся. удяляются предлоги. приводятся к единой форме). Это теория. Как это реализовано в MySQL - я ХЗ. В Postgres это точно есть. Один чел выше уже написал.

Лучше звездочку не использовать по двум причинам.

Первое - это объем сетевого трафика. Если в таблицу будет добавлено 4 поле например типа BLOB и туда
будут вставлять картинки - то при каждом select * ... картинка будет транслироваться по сети даже если
она вам не нужна.

И второе - просто неожиданно поведение софта, который ожидает поля именно в этом порядке
id, name, balance
если кто-то захочет поменять тип данных name например - то он сделает drop column name, а потом
создаст новое поле alter table add column .... то в таблице они лягут в заголовок уже в новом порядке
id, balance, name
Какие будут последствия - чорт его знает но ничего хорошего для автоматизированных систем ждать
не стоит.

Вобщем всегда указывайте явно поля.

Надо ли учить PHP и MySQL?

Считается что PHP/MySQL относятся к "морально устаревшему" стеку технологий (LAMP (lin+apache+mysql+php).
(Я думаю что знания MySQL полезны. Это лучше чем "никакой" SQL.)

На смену ему должен был выйти лет 7 назад MEAN (mongo+nodejs+....e.t.c.).
Мне уже поздно переходить в MEAN. Слишком стар. Но я-бы перешел просто потому что это
более новый взгляд на старое. Новое - всегда лучше чем старое.

Учу веб-разработку для фриланса - делать сайты на заказ (знаю, что рынок супер конкурентный). По книжкам выучил JS, HTML, CSS, базовый jquery (*тут могла быть ваша шутка*), к фреймворкам и библиотекам пока не приступал.

По поводу "размещать сайт". Это вообще не твоя основная цель. Цель - набить руку в системе.
Для этого тебе не нужно иметь свои хостинги. А нужно просто влиться в систему которая уже
их делает в режиме конвейера.

По поводу "выучил по книжкам". Ты не выучил еще ничего. И дело даже
не в техниках верстки. А ты пока не понял как работает процесс коллективной разработки софта.
Это сложно. Это интересно и эффективно. И ты будешь эффективнее в команде а не во фрилансе.
Работа в команде - это не только код. Это согласование ТЗ. Документирование.
Скрам-процессы. Корпоративная этика и кодекс поведения. Это как лак для дерева.
Ты - пригож для всех корпораций после этого. А во фрилансе хоть 40 лет просиди.
Никто характеристики не даст и не впишеться.

Поэтому лучше пойди в корпорацию. Покрутись несколько лет. Получи своё видение. И потом
уже во фриланс если будет желание.

Хочу понять, насколько глубоко надо лезть в бэкэнд

На этот вопрос сложно ответить. Ты скорее сам почувствуешь. Опять-же после опыта в корпорации.
Кстати и развиваться можно внутри корпораций вполне себе хорошо. И курсы и тренинги и сертификация.
ИЧСХ тебе корпорация их и оплатит.

В SQL - много таких особенностей. Тоже самое с group by и оконными фунециями. Надо много повторяющихся expressions написать.

Попробуй еще так написать.

WITH HT AS (
 SELECT `product_id`, MD5(`value`) AS myhash
  FROM modx_ms2_product_options
  LIMIT 10
)
SELECT * FROM HT WHERE `myhash` = 'e59253548ffcb090ecc0cd0944afd27f'

Для начал посмотри что в них внутри. Вот как тут пишут https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlo...
Может это и не ты накрутил а просто новая версия прикладного софта работает. Что-то обновляет интенсивно.

Скорее всего такого готового функционала нет. Но любой думающий девопс или dba сможет
сделать семейство скриптов которые делают полный экспорт во временную базу и потом
в этой временной БД делают drop column ... или лучше update set = null. И еще раз полный
экспорт в файлы.

Эти скрипты вобщем делаются быстрее чем мы здесь сидим и обсуждаем. Поэтому
не ждите. Начинайте делать.

UPD:

Если они связаны 1:1 то соедини их в одну табличку и все.

UPD: Автор если ты сомневаешся - то лучше не делай. На все технические вопросы тут ответят.
Но риски - это дело твоё. Похлопывать тебя по плечу или давать санкции на авантюры - никто не будет.
Если ты отвественный за БД и уверен в себе - то иди и делай.

Типа можно накатить изменения и также безопасно откатить.

По поводу безопасного отката. Это на 99% зависит от SQL кода который вы напишете. Это никак не связано с фреймворком поддержки миграций. Берите какой угодно фреймворк. Например liquibase или flyway.

И даже в них если во время alter table rename column вы столкнетесь с активными сессиями в БД - то ваша транзакция переименования упадет и вы будете вручную решать ситуацию отката или наката.

Безопасность наката и отката также зависит от грамотности описания ваших чендж-сетов. Бывает так что в 1 чендж-сет запихивают 2 DDL команды и одна из них проходит а вторая не проходит и фреймворк повисает навсегда в клинче. Двигаться назад он не может т.к. Не был применен чендж-сет. И двигаться вперет тоже не может т.к. первая DDL команда уже выполнена и повторо ее вызывает ошибку типа "table/index already exists".

Выводы - грамотность описания чендж-сетов. И все.

Ваш фреймворк phinx выглядит ужасно с точки зрения кода. Как по мне он не делает главной задачи а именно - не является DSL для upgrade/rollback. Он - прибит гвоздями к PHP и следовательно его можно рассматривать только под углом вашего PHP-удобства. Удобен он вам? Используйте.