и без подзапроса

у тебя везде join, оператор симметричный

Попробую, спасибо. Меня смущает, что для tbl1, tbl2 и tbl3 нужно по селекту делать.

ну это интересно конечно: получить данные из таблицы, не делая селект

попахивает магией

Да, я не про отсутствие селекта в целом, а про то можно ли в одном селекте всё провернуть и вывести в 3 таблицы.

select * from ?

Тогда всё выведется в одну.

какие-то у вас совсем специфические задачи

Да я сам уже на стену лезу. Возможно формулирую как-то неправильно.

а чем не устраивает одна результируюзщая таблица? в коде обрабатывать неудобно типа?

Есть 3 таблицы, в соседних таблицах смотрю, что из менилось и если поменялся tbl1_id в таблице tbl1, то вернуть надо не только его, но и все пересекающиеся с ним результаты из tbl2 и tbl3, при этом tbl1_id есть в tbl2, и уже через tbl2_id связан со значениями tbl3.

выгребать одну результирующую таблицу и делать diff в коде

Результирующих ведь тоже 3 получается, для проверки обновлений по tbl1_id в tbl1, tbl2, tbl3, проверки tbl2_id в tbl1, tbl2, tbl3, и проверки tbl3_id в tbl1, tbl2, tbl3;

потому что в реалиях mvcc и всяких этих ваших хайлоадов это снижение производительности и накладные расходы

производительность <<< корректность выполнения

не понимать что значат треугольные скобки

много меньше

проивзодительность менее важна, чем корректность

корректость выполнения можно обеспечивать на разных уровнях, не обязательно всю логику упаковывать в базе

и да я там писал, что они нужны, но применять стоит с умом

можно и на уровень приложения вынести, только быстрее это не будет )

ему ровно так же надо будет проверить существование родительской сущности

Я не раз видел сообщения об отказе от ФК в нагруженых сервисах, но чаще всего речь шла про микросервисную архитектуру, где нельзя рассчитывать, что два сервиса смотрят в одну базу. В общем это вполне себе способо повысить производительность, но я бы просто не стал относиться к нему настолько критично.

Привет, может кто-нибудь пояснить про функциональную зависимость. Есть таблица {A, B, C, D, E, F} , что значит функциональная зависимость B → {C,D} ?

Это по-моему даже в вики про НФ есть

Если кому было интересно как решалась вчерашняя моя задача: create temporary table tmpTbl1 select i.Tbl1_id, i.some_id from Tbl1_Version v inner join Tbl1 i on i.Tbl1_id = v.Tbl1_id where v.version between @cache_version and @global_version union select i.Tbl1_id, i.some_id from Tbl2_Version v inner join Tbl2 n on n.Tbl2_id = v.Tbl2_id inner join Tbl1 i on i.Tbl1_id = n.Tbl1_id where v.version between @cache_version and @global_version union select i.Tbl1_id, i.some_id from Tbl3_Version v inner join Tbl3 c on c.Tbl3_id = v.Tbl3_id inner join Tbl2 n on n.Tbl2_id = c.Tbl2_id inner join Tbl1 i on i.Tbl1_id = n.Tbl1_id where v.version between @cache_version and @global_version; select i.Tbl1_id, i.some_id from tmpTbl1 i; select n.Tbl2_id, n.Tbl1_id from tmpTbl1 i inner join Tbl2 n on n.Tbl1_id = i.Tbl1_id; select c.Tbl3_id, c.Tbl2_id from tmpTbl1 i inner join Tbl2 n on n.Tbl1_id = i.Tbl1_id inner join Tbl3 c on c.Tbl2_id = n.Tbl2_id; drop table if exists tmpTbl1;

господа, я правильно понимаю - в мускуле optimize table делает копию таблицы, вычищенную от говна. Т.е. для операции надо 2x<размер таблицы на фс> дискового пространства?

йеп

только почему 2х

ну это в худшем случае

он будет делать временную таблицу, если толстая - свапать на диск

вот у меня таблица на 300 гиг

я не думаю что у меня свап поможет )

свапать в смысле конвертить таблицу на диск

из памяти

вот у меня таблица на 300 гиг

foreign_key_checks = 0, ёбай все ключи и индексы и потом после оптимайза вешай их обратно

если есть такая возможность

эта таблица приложения - не хотелось бы ей менять параметры

т.е. вы не можете позволить себе мейнтенс?

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

да в принципе можем, только удаление-навешивание усложнит maintance

т.е. сейчас стоит проблема - найти место в фс для optimize table, если ее устранить то место освободится в любом случае

стоит ли вешть снимать индексы?

и тд

стоит ли вешть снимать индексы?

это только для того, чтобы сам оптимайз быстрее прошел

да это пофиг

посмотрим на более мелких - будет если совсем затратно по времени, тогда будем прнимать меры

вообще дока базарит, что можно сделать это как online DDL

и типа всё красиво и не так грустно

я видел, но не очень понял этот момент

The “Rebuilds Table?” column shows which operations rebuild the table. For operations that use the INPLACE algorithm, the table is rebuilt in place. For operations that do not support the INPLACE algorithm, the table copy method is used to rebuild the table.

типа на ходу можно колбасить таблицу?

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

ну, по идее, как я читал талица суть linked list

поэтому удаленные записи все равно там висят

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

и думаю такое возможно, только если будет лок на таблице

без этого я вообще не представляю

поэтому удаленные записи все равно там висят

по-идее не должны

там старые версии строк храняться только в пределах сегмента отката, пока ты всё не зафлушил во все нужные места

а потом меняется чекпоинт и все по новой

иначе была бы такая же хуета как postgresql с его vacuum и wraparound

удалённые данные всё равно могут занимать место (хотя это не linked list). если вставили большое количество записей, а потом удалили, purge конечно пройдёт и удалит. удалит в том смысле, что сделает занимаемое ими место доступным для повторного использования

будет ли это место повторно использовано — отдельный вопрос

будет

если будет вставлено достаточное количество новых записей. иначе не будет

поэтому да, может понадобиться optimize table

который может выполняться inplace. в том смысле, что копирование всё равно будет, но данные в индексы будут вставляться оптимизированным образом

т.е. он просто обновление на месте сделает

да, и online в том смысле, что он DML будет записывать в отдельный журнал "сбоку", а после завершения optimize table приложит изменения

блокировки ему конечно всё равно нужны в самом начале и в самом конце optimize table. но они кратковременные

Spam

/Spam

Во, бот выполняет своё дело :)

От команды /spam теперь есть практическая польза?

В смысле, можно написать её и не тревожа админов, спам будет очищен?

Это здорово, если так

Товарищи, а вы используете mysql или mariabd тоже?

В смысле, можно написать её и не тревожа админов, спам будет очищен?

Да. Если три раза пользователи пометили сообщение этой командой, то оно удалится.

Товарищи, а вы используете mysql или mariabd тоже?

Обычно второе поставляется в репозиториях. Ибо Maria быстрее, чем стандартный сервер MySQL.

Обычно второе поставляется в репозиториях. Ибо Maria быстрее, чем стандартный сервер MySQL.

гкхм

Всем привет! Есть табличка вида id | name | mp_id | md_id | ch_id | ca1_id | ca2_id | ca3_id | ca4_id 1 | One | 1 | 1 | 3 | 1 | 7 | 22 | 7

2 | Two | 2 | 3 | 3 | 5 | 3 | 10 | 4

и так далее. а так же табличуи для каждого *_id вида id | value 1 | val1 2 | val2

как получить табличку вида 1 | One | mp_val1 | md_val1 | ch_val3 | ca_val1 | ca_val7 | ca_val22 | ca_val_7