|
|
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Добрый день! Необходимо обновлять набор из 100-150 опций типа TINYINT (1/0 -> true/false). К сожалению, не все так просто как во вставке и приходится ухищряться. Часто вижу предложения типа: UPDATE mytable SET myfield = CASE other_field WHEN 1 THEN 'value' WHEN 2 THEN 'value' WHEN 3 THEN 'value' END WHERE id IN (1,2,3) Но эта штука катит в mysql 5.1, к примеру, и совсем не катит в v5.5. А на сервере у меня конечно же mysql v5.5. Сделал для теста 24 отдельных update и это на таблице с 40 записями заняло 0.35 сек. При update 150 записей на таблице с 10.000 записей представляю, как это будет работать. Подскажите что-нибудь? Как такие вещи правильно делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 11:04:41 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120представляю, как это будет работать.Ровно так же, если на поле id есть индекс. И вообще разница между 40 и 10000 записей в такой задаче ничтожна. Вот если бы у вас было миллионов 10-20 записей, тогда можно было бы о чём-то думать... Nicolai6120катит в mysql 5.1, к примеру, и совсем не катит в v5.5.конкретнее? каковы ваши критерии "катибельности"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 11:39:31 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120Необходимо обновлять набор из 100-150 опций типа TINYINT (1/0 -> true/false).Сколько бы там не требовалось обновлять записей - достаточно 2 запросов.Которые к тому же можно отправить на сервер одной строкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 12:12:58 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
akina, это изведвательство))) Скажите же мне эти 2 чудо запроса) // По поводу критериев катибельности: на 5.1 один и тот же запрос работает, а на 5.5 - проходит без ошибок, но не делает изменений никаких в таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 15:59:58 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120на 5.5 - проходит без ошибок, но не делает изменений никаких в таблице.Дело не в версии как таковой, а в запросе/таблице/настройках/данных. Что-то отличается от того места, где версия 5.1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:11:34 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120Скажите же мне эти 2 чудо запросаПодозреваю, что такие: Код: sql 1. 2. 3. Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:13:14 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120Скажите же мне эти 2 чудо запроса Я не понял... ну тут вовсе не нуждно быть семи пяток во лбу-то... Nicolai6120Необходимо обновлять набор из 100-150 опций типа TINYINT (1/0 -> true/false).Т.е. значений назначения - всего два. Ну и Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:16:24 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
ооо мерси! о таком варианте я и не подумал. У меня ведь и правда всего 2 возможных значения. // А что касается настрое и прочего...Запрос один и тот же, таблица простая как 2 пальца (в обеих mysql с одного дапма взята). Методом исключения остается настройка какая-то....но я не подозреваю, какая настройка могла бы так изменить поведение стандартного CASE оператора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:18:58 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Nicolai6120А что касается настрое и прочего...Запрос один и тот же, таблица простая как 2 пальца (в обеих mysql с одного дапма взята). Методом исключения остается настройка какая-то....но я не подозреваю, какая настройка могла бы так изменить поведение стандартного CASE оператора.Это было сказано в широком смысле, поскольку видно, что вы показываете не настоящий боевой запрос, а лишь его модель. Конкретно настройки могли бы играть роль в случае с разными кодировками и, возможно, в случае с неявными преобразованиями типов. Попробуйте примерно так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. И будет видно в каких строках что на что должно измениться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:24:30 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Не люблю делать из людей экстрасексов, поэтому: 1. боевой запрос UPDATE option_value SET value = CASE id WHEN 1 THEN 0 WHEN 2 THEN 0 WHEN 3 THEN 0 END WHERE id IN (1,2,3) 2. частичный дамп -- -- Структура таблицы `option_value` -- CREATE TABLE IF NOT EXISTS `option_value` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `option_id` int(10) unsigned NOT NULL, `hotel_id` int(10) unsigned NOT NULL, `room_cateory_id` int(10) unsigned DEFAULT NULL, `option_value_name_id` int(10) unsigned DEFAULT NULL, `value` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=46 ; -- -- Дамп данных таблицы `option_value` -- INSERT INTO `option_value` (`id`, `option_id`, `hotel_id`, `room_cateory_id`, `option_value_name_id`, `value`) VALUES (1, 1, 100, 17, NULL, '0'), (2, 2, 100, 18, NULL, '0'), (3, 3, 100, NULL, NULL, '0'); Вот на такой таблице я все это и проверял. Кстати Ваш вариант для проверки, насколько я понял, должен выглядеть примерно так при моей реальной стуктуре таблицы SELECT id, value, CASE option_id WHEN 1 THEN 0 WHEN 2 THEN 0 WHEN 3 THEN 0 END value FROM option_value WHERE id IN (1,2,3) При выполнении дает и там и там одинаковый результат. То есть данная проблема проявляет себя только в том запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 16:48:15 |
|
||
|
групповой UPDATE
|
|||
|---|---|---|---|
|
#18+
Хм, а как именно вы проверяли, что "не делает изменений никаких в таблице" ? В приведенном дампе ничего измениться и не должно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 17:16:34 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38841892&tid=1833762]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
148ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 483ms |

| 0 / 0 |
