ayazer

https://dev.mysql.com/doc/refman/8.0/en/join.html

SELECT o.address, u.name, u.phone
FROM `objects` o
JOIN `users` u on o.userID = u.userID
WHERE o.userID=12 
ORDER BY o.created_at 
OFFSET 1 rows 
FETCH next 1 rows only

pt-online-schema-change/gh-ost и не страдайте

есть 2 проверенных варианта:
1) github gh-ost.
2) percona toolkit

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

percona toolkit - работает через триггеры. потому мигрировать таблицу для которой уже есть триггеры не выйдет. но зато она работает быстрее

gh-ost - читает бинлог. соотв. будет работать даже если есть триггеры, но работать будет медленно (в моем случае он переливал данные с где-то с такой-же скоростью как они добавлялись)

в итоге я в свое время использовал для миграций перкону. миграции мелких таблиц в пару гигабайт проходили в течении 10-15 минут незаметно для бекенда.

mysql 8.0 + ? тогда

UPDATE products SET full_description = REGEXP_REPLACE(full_description, "<h2.+>", "<h2>");

https://dev.mysql.com/doc/refman/8.0/en/regexp.htm...

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

С другой - надо посмотреть на предметную область и подумать - а дейстительно ли есть есть смысл в разделении? На вид конкретно в данном случае - майскл используется как key-value хранилище, которое быстро достает список документов и отдает его наружу. Дальше сервис уже сделает сплит по запятой и пойдет доставать документы куда-то с хранилища/пойдет куда-то в солр/еластик чтоб уточнить информацию по каждому конкретному документу. Т.е. в случае если нам всегда нужен весь список документов - мы имеем ситуацию когда от разделения мы только теряем (т.к. больше таблиц, больше джойнов, сложнее структура, больше цпу/рам тратится чтоб все достать/хуже кеш хит => мы можем выдержать меньшую нагрузку).

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

ну так обновите метод чтоб обновлять сразу все значения что вам нужны

UPDATE chats SET {name1}={value1}, {name2}={value2}, ...., {nameN}={valueN} WHERE chat_id = {chat_id}

https://dev.mysql.com/doc/refman/8.0/en/update.html

result_vk_user_id = cursor.fetchall()

Такой селект выводит вот такую ерунду:
[(323826602,)]

это не ерунда а массив кортежей. вы же сами написали что с базы нужно достать все значения. Если нужна только одна строчка - используйте fetchone.

ну и да, нужное вам значение лежит в
result_vk_user_id[0][0]

upd:
ну или можно просто избавится от кортежей и получить список значений

result_vk_user_ids = [rec[0] for rec in cursor.fetchall()]

нет. главное чтоб в where были или первое поле, или первых два поля, или все 3 поля. в каком порядке вы их напишете в запросе - без разницы.

т.е. where country = ?? использовать индекс не будет вообще, а where country = ?? and entityId = ?? будет использовать только первую часть составного индекса (по ентитиИд).

create trigger <trigger_name> before insert on <table_name>
for each row
begin
if new.val = '' then
signal sqlstate '45000';
end if;
end;$$

и аналогичные триггеры для before delete/before update

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