-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Mysql: update low_priority - время выполнения
- Автор темы confguru
- Дата начала
slach
Новичок
все зависит от того что MySQL лочить будет во время UPDATE... таблицу или только строки...
WHERE id=y - это сколько записей?
во время UPDATE - SELECT'ы в этот диапозон идут?
LOW_PRIORITY - задержит время выполнения... если не ошибаюсь
потому как LOW_PRIORiTY это нифига не DELAYED ... который возвращает в скрипт сразу
WHERE id=y - это сколько записей?
во время UPDATE - SELECT'ы в этот диапозон идут?
LOW_PRIORITY - задержит время выполнения... если не ошибаюсь
потому как LOW_PRIORiTY это нифига не DELAYED ... который возвращает в скрипт сразу
camka
не самка
С LOW_PRIORIORITI все запросы на обновление будут пропускать вперед все запросы на выборку из той же таблицы. То есть ждать результата придется дольше в случае, если одновременно идет несколько выборок на ту же таблицу. По умолчанию UPDATE запросы имеют высший приоритет, чем SELECT, поэтому они теоретически будут выполняться быстрее, поскольку никого вперед себя они пропускать не будут.
А вообще, стоит почитать мануал.
http://dev.mysql.com/doc/refman/5.0/en/locking-issues.html
http://dev.mysql.com/doc/refman/5.0/en/update.html
А вообще, стоит почитать мануал.
http://dev.mysql.com/doc/refman/5.0/en/locking-issues.html
http://dev.mysql.com/doc/refman/5.0/en/update.html
camka
не самка
Не вижу связи ни с опытом ни с количеством записей. Вполне понятно, что будет мендленнее, поскольку ждать дольше. Поясните или приведите пример, в каком случае, вы видите, возможен прирост в скорости отработки UPDATE запроса при понижении его приоритета.
Это не INSERT DELAYED, как уже заметил ранее тов. slach, который возвращается _до_ выполнения непосредственно самого запроса, ставя его в очередь. Здесь он будет ждать до упора, пока освободится очередь к таблице, и только потом возвращать результат, из которого можно будет выудить количество измененных записей и т.п.
Это не INSERT DELAYED, как уже заметил ранее тов. slach, который возвращается _до_ выполнения непосредственно самого запроса, ставя его в очередь. Здесь он будет ждать до упора, пока освободится очередь к таблице, и только потом возвращать результат, из которого можно будет выудить количество измененных записей и т.п.
