|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день. Есть некая таблица пользователей. Есть 6 полей, которые нужно два раза обновить полностью по всей таблицы.
При 50 000 проблем с обновлением не было. Но сейчас 250+ появилась: при обновлении таблица блокируется(как я понял), и не выполняется запрос Update от пользователей. Как решить эту проблему, чтобы при обновлении сервером всей таблицы она не блокировалась? Или может есть другой способ...
UPDATE Characters SET yeday_money=today_money, yeday_ranking=today_ranking, yeday_brains=today_brains;
UPDATE Characters SET today_money=0, today_ranking=0, today_brains=0
viewer_id int(11) PRI
today_money int(11) NO MUL 0
today_ranking int(11) NO MUL 0
today_brains int(11) NO MUL 0
yeday_money int(11) NO MUL 0
yeday_ranking int(11) NO MUL 0
yeday_brains int(11) NO MUL 0
Отредактированно afrokick (20.06.2012 13:20:21)
Неактивен
При обновлении всей таблицы она будет блокироваться в любом случае. Нужно думать в направлении изменения архитектуры - так, чтобы не приходилось всем одновременно обновлять всю таблицу.
Неактивен
UPDATE Characters SET yeday_money=today_money, today_money=0, ... ?
Неактивен
vasya написал:
UPDATE Characters SET yeday_money=today_money, today_money=0, ... ?
Начал недавно работать, и была мысль, что если так напишу, то может сначала today_money=0 выполниться, а затем yeday_money=today_money . Развейте мой миф пожалуйста. это ведь не так?)
хмм, обновление выполняю один раз в 24 часа. И нужно пробежаться по всей таблице. Если интервал задавать с помощью LIMIT X,Y, то дело пойдет на лад?
Неактивен
http://dev.mysql.com/doc/refman/5.0/en/update.html написал:
Single-table UPDATE assignments are generally evaluated from left to right. For multiple-table updates, there is no guarantee that assignments are carried out in any particular order.
Неактивен
rgbeast
понял, спасибо.
Если интервал задавать с помощью LIMIT X,Y, то дело пойдет на лад?
А по этому поводу что скажете?
И еще вопросик. Есть запрос, который возвращает ~20 000 уникальных ключей, и потом я делю на части по 100 и обновляю, использую WHERE id=key1 or id = key2 or id = key3... можно ли как-то объединить два запроса? Мне нужно по-любому возвратить ключи тех, кого обновил. В голове вертится что-то типа
SELECT id FROM characters WHERE UPDATE characters WHERE "условия обновления"
Как быть?
Неактивен
afrokick написал:
Если интервал задавать с помощью LIMIT X,Y, то дело пойдет на лад?
Будет меньше время блокировки, может помочь. Но лучше не LIMIT, а диапазон по id - WHERE id>0 and id<100, например.
afrokick написал:
И еще вопросик. Есть запрос, который возвращает ~20 000 уникальных ключей, и потом я делю на части по 100 и обновляю, использую WHERE id=key1 or id = key2 or id = key3... можно ли как-то объединить два запроса? Мне нужно по-любому возвратить ключи тех, кого обновил. В голове вертится что-то типа
SELECT id FROM characters WHERE UPDATE characters WHERE "условия обновления"
Как быть?
Сделать, чтобы UPDATE возвращал что-то в формате SELECT в MySQL нельзя.
Неактивен
Возвращаюсь к первому вопросу. При таком запросе
UPDATE Characters SET
yeday_money=today_money, today_money=0,
yeday_ranking=today_ranking, today_ranking=0,
yeday_brains=today_brains, today_brains=0 WHERE
today_money<>0 or today_ranking<>0 or today_brains<>0
не будет уже блокироваться вся таблица? ( мы же вроде как уникальные записи выбираем)?
Неактивен
Будет блокироваться. Вся таблица не блокируется, если запрос позволяет легко идентифицировать изменяемые записи по первичному ключу (например id=10 или id>10 AND id<20).
Неактивен
Хм, т.е. можно через SELECT выбрать те ид, которые нам нужны, а потом UPDATE сделать для них, и это будет быстрее?
Неактивен
Ну да, чем меньше записей обновится, тем быстрее запрос отработается. Ну и конечно, нужно проследить, чтобы сам SELECT быстро отработал.
Неактивен
afrokick написал:
Хм, т.е. можно через SELECT выбрать те ид, которые нам нужны, а потом UPDATE сделать для них, и это будет быстрее?
да, апдейт по конкретным id заблокирует только обновляемые строчки, поэтому предварительный SELECT упростит блокировку.
Неактивен
deadka,rgbeast
Спасибо
И еще вопросик назрел) UPDATE ... WHERE id IN(массив) - где-то читал что IN не очень хорош. ТАк ли это и что можно взамен?
Неактивен
Если нельзя заменить на RANGE, то как вариант только JOIN с временной таблицей. А чем плохо IN?
Неактивен
