нету, надо создать?

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

нет, значит и next key lock не будет. да если бы и был, ничего страшного бы не случилось

ага, если индекса не будет - будет блокировка по праймари что ровняется чему? прааавильно локу всей таблицы

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

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

ага, если индекса не будет - будет блокировка по праймари что ровняется чему? прааавильно локу всей таблицы

что за бред?

это не бред, это документация)

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

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

это какая-то документация из параллельной вселенной

и никакой индекс не нужен

это какая-то документация из параллельной вселенной

Record locks always lock index records, even if a table is defined with no indexes. For such cases, InnoDB creates a hidden clustered index and uses this index for record locking. Если у тебя будет тип доступа ALL сколько строк ты заблокируешь?

ой, так ну это ж не о том совсем

а о чем же?

о том, что если таблица определена без индексов, то создаётся скрытый clustered index из row id

Если у тебя будет тип доступа ALL сколько строк ты заблокируешь?

даже по кластерному индексу

Проведи простой эксперимент: START TRANSACTION; SELECT * FROM foo f WHERE f.entity <> 1 FOR UPDATE; COMMIT; START TRANSACTION; SELECT * FROM foo f WHERE f.id = 2 FOR UPDATE; COMMIT;

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

а во второй выборка по праймари

конструкция FOR UPDATE даёт тот же лок что и UPDATE и DELETE

ох щщи

значит UPDATE на таблице на 9 миллионов записей поставит record (не next-key) локи на все обновляемые записи. это независимо от того, какой индекс используется (и используется ли вообще)

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

это однако не имеет ничего общего с блокировкой таблиц. особенно в случае insert (append-only) запросов — они вообще никаких блокировок не увидят

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

это однако не имеет ничего общего с блокировкой таблиц. особенно в случае insert (append-only) запросов — они вообще никаких блокировок не увидят

ты не прав

да. но нет

есть такая штука как блокировка автоинкремента, например

есть, да. не про нас это

есть, да. не про нас это

ну замени во второй транзакции селект на insert )

потом вместе посмеемся)

да я как бы и не смеюсь. в какой второй транзакции?

Проведи простой эксперимент: START TRANSACTION; SELECT * FROM foo f WHERE f.entity <> 1 FOR UPDATE; COMMIT; START TRANSACTION; SELECT * FROM foo f WHERE f.id = 2 FOR UPDATE; COMMIT;

вот тут

так там две транзакции делают SELECT FOR UPDATE на всю таблицу. это вообще каким боком здесь?

во первых не на всю

можно было просто сделать select get_lock() и сказать: "вот, видишь, блокировки!"

@etkee ты удачно зашел, присоединяйся, бери попкорн

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

можно было просто сделать select get_lock() и сказать: "вот, видишь, блокировки!"

эти блокировки не имеют ничего общего с блокировкой строк

так и пример ничего общего не имеет

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

Почему же?

а почему же имеют?

так и пример ничего общего не имеет

я сэмулировал тебе блокировку всей таблицы селектом

точно такую же

как и при блокировке апдейтом

ну круто. я предложил более короткий вариент "блокировки всей таблицы"

ну, во-первых она не точно такая же. подумай про isolation levels, например

ну, во-первых она не точно такая же. подумай про isolation levels, например

такая же, и при одинаковом уровне изоляции результат тот же

а во-вторых, даже в твоём примере блокировки таблицы нет. оно к конце выполнения заблокирует все записи. ну круто, да. и это доказывает, что UPDATE на всю таблицу всю таблицу же и заблокирует?

а, то есть все записи таблицы это не вся таблица да?

сложный прикол

а, то есть все записи таблицы это не вся таблица да?

новые могут insert делать

а если вся таблица, то insert незя

новые могут insert делать

я не с проста написал потом

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

так ты лочишь всю таблицу

специально через for update

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

Блин, ребят, смысла спорить нет, потратьте 5 минут своего драгоценного времени, проверьте

а, ну ok

Блин, ребят, смысла спорить нет, потратьте 5 минут своего драгоценного времени, проверьте

так понятно, что не даст выполнить

никто не спорит

уже спор о названиях

не даст выполнить именно из-за for update кстати

не даст выполнить именно из-за for update кстати

так и я об этом

@acromegale слушай, у меня мысль возникла. а вы с @etkee не бадушники случайно?

@acromegale слушай, у меня мысль возникла. а вы с @etkee не бадушники случайно?

ноуп

вот это прям оскорбление века было

ok. да нет, я просто подумал, ничего лично :)

да я не серьезно

не даст выполнить именно из-за for update кстати

for update вешает такой же exclusive lock как и апдейт и делит - селекты чисто для наглядности

но в дейтинг вообще никогда не пойду, как и в продажу спиннеров, вейпов, казино, мфо, бинарные опционы и прочие эм вакансии

for update вешает такой же exclusive lock как и апдейт и делит - селекты чисто для наглядности

for update использует именно next-key locks. которые не используются в update при read-committed, например

for update использует именно next-key locks. которые не используются в update при read-committed, например

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

и да, кстати

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

разговор был за обновление по колонке без индекса

а это всё равно. ну будет индекс, и что?

будет индекс - будут заблокированы только записи по этому индексу, которые подходят по условию без индекса будет фулл тейбл

блин, мне уже чесслово надоело

какому условию? мы про full-table update говорим

Обновление всей таблицы или обновление n строк по неиндексной колонке одинаково блокирует все записи

сколько раз я еще это должен сказать

чтобы вы поняли

да мы поняли. но мой вопрос без ответа остался

какой именно

или вот ещё вопрос на засыпу: может ли update по неиндексной колонке использовать индекс?

какой именно

какому условию? мы про full-table update говорим

вот этот

или вот ещё вопрос на засыпу: может ли update по неиндексной колонке использовать индекс?

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

какому условию? мы про full-table update говорим

тут я имел ввиду что ты будешь отфильтровывать в where

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

ответ неверный

Хорошо, давай верный

правильный ответ: UPDATE может использовать любой доступный индекс (или не использовать вообще) на усмотрение оптимизатора. для блокировок строк pimary key не требуется

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

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

блокировка строки — это такая сущность, которая вообще не привязана к индексам. она состоит из номера tablespace-а, номер страницы и битовой маски заблокированных на странице записей

мужики какими IDE пользуетесь под линукс?

есть ли IDE на подобие dbForge под линукс?