Форум на Исходниках.RU https://forum.sources.ru Форум на Исходниках.RU Форум на Исходниках.RU https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694572 Sun, 20 Nov 2016 21:11:29 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694572 Цитата Dart_Sitius @
что-то такое?

Близко не лежало. Я ж русским по белому отрисовал - сперва заливка, потом индексация.
Более того - вот попробуй мне на основании только опубликованного тобой доказать, что временная таблица размещена в памяти...

Цитата Dart_Sitius @
Версия MySQL 5.1.73-log.

Можешь половину вышенаписанного смело забыть - на такой старой версии всё это неактуально.]]> Akina Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694570 Sun, 20 Nov 2016 20:38:53 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694570 Цитата
"Убивать" SSD не особенно то и надо

На хостинге не страшно ничего "убивать", я ему плачу за это.
Цитата
Задери RAM по самое "нехочу"

Даже 16Гб может не хватить

Добавлено
В том варианте, который я написал, к сожалению только дольше.
show processlist; показывает, что на preparing тратится около 130 секунд, а суммарно вместе с closing tables около 160 секунд.
без использования временной таблицы было 50 секунд на запрос и 30-40 на closing tables. Может я что-то сделал не так?

Буду эксперементировать с InnoDB

Добавлено
хм, у меня оказывается оператива была забита (проверил в free -m). Почистил, теперь обычный запрос выполняется 25 вместо 56, а closing tables 10 вместо 30 секунд, т.е суммарно 35 секунд]]> Dart_Sitius Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694567 Sun, 20 Nov 2016 20:29:44 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694567 Цитата Akina @
Начиная от SSD и заканчивая зеркалом таблицы в памяти

Все абсолютно верно! За исключением пару "но":
  • "Убивать" SSD не особенно то и надо ... если вообще можно не убивать, мы же не киллеры :)
  • Задери RAM по самое "нехочу" - это будет а) Дешевле SSD б) Быстрее SSD в разы ... одна беда - сброс кэша, но это - пыль а не вопрос
]]> JoeUser Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694560 Sun, 20 Nov 2016 19:41:20 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694560 Цитата
Каков объём одной записи? (строки - это в экселе)...

Около 100 байт.
Цитата
Просто потому, что ни версии сервера, ни иных сведений нам не озвучено. Да и движок MyISAM - даже не распараллелить обработку.

Хм, и действительно. InnoDB в данном случае похоже должен дать выигрыш. Версия MySQL 5.1.73-log.
Цитата
и только потом UPDATE. И тогда при достаточно свежей версии сервера появляется надежда вместо fullscan получить index merge

ок, спасибо, попробую

Добавлено
            mquery("CREATE TEMPORARY TABLE `tmp_update`(PRIMARY KEY (`id`), KEY (`storage_id`) USING BTREE) AS ".
                "(SELECT `id`, `storage_id` FROM `$sql_table` WHERE $where LIMIT $limit)");
            mquery("UPDATE `$sql_storage` SET ".$value[1]." WHERE `id` IN (SELECT `storage_id` FROM `tmp_update`)");
            mquery("DELETE FROM `$sql_table` WHERE `id` IN (SELECT `id` FROM `tmp_update`)");
            mquery("DROP TABLE `tmp_update`"); // потому что в цикле

что-то такое?]]> Dart_Sitius Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694555 Sun, 20 Nov 2016 19:18:36 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694555 Цитата Dart_Sitius @
Зеркало в памяти 40млн строк к сожалению невозможно.

Каков объём одной записи? (строки - это в экселе)...

Цитата Dart_Sitius @
Если в таблице есть индекс, то без разницы какого она размера? Имею ввиду, что если бы данная таблица была скажем не 40млн записей, а 5млн, но при этом в запросе мне все равно нужно было обновить 150к строк, то работало бы все те же 70 сек?

Я даже сейчас не стал бы наверняка утверждать, что индекс используется. Просто потому, что ни версии сервера, ни иных сведений нам не озвучено. Да и движок MyISAM - даже не распараллелить обработку.

Цитата Dart_Sitius @
что даст то, что я размещу ID во временной таблице?

Ты проглядел главное - ИНДЕКСИРОВАННАЯ таблица. То есть предполагается, что будет
CREATE TEMPORARY TABLE (id)
INSERT INTO TEMPORARY TABLE (id) VALUES (...)
CREATE PRIMARY INDEX ON (id)
и только потом UPDATE. И тогда при достаточно свежей версии сервера появляется надежда вместо fullscan получить index merge.]]> Akina Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694552 Sun, 20 Nov 2016 19:06:05 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694552 Akina, спасибо за оперативный ответ.
Заносить ID во временную таблицу - хорошая идея, так и сделаю.
А вот таблица и так на SSD =( Зеркало в памяти 40млн строк к сожалению невозможно.

Заодно задам вопрос, который меня давненько мучает. Если в таблице есть индекс, то без разницы какого она размера? Имею ввиду, что если бы данная таблица была скажем не 40млн записей, а 5млн, но при этом в запросе мне все равно нужно было обновить 150к строк, то работало бы все те же 70 сек? (хотя это легко сейчас проверить на практике, но в теории же так оно?)

Добавлено
Хотя стоп, а что даст то, что я размещу ID во временной таблице?
Сейчас я делаю весь апдейт в одну строку UPDATE `table` SET `data`=`data`+1 WHERE `id` IN (1,2,3,...150000)
Если я занесу в таблицу, то он превратится в
CREATE TABLE`tmp`...
INSERT INTO `tmp`(`id`) VALUES 1,2,3,...150000
UPDATE `table` SET `data`=`data`+1 WHERE `id` IN (SELECT `id` FROM `tmp`)
Разве это быстрее?]]> Dart_Sitius Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694550 Sun, 20 Nov 2016 18:59:15 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694550
Куда копать? ускорять работу с таблицей, вероятно.

Первое - заносить весь этот набор ID во временную таблицу, размещённую в памяти. Индексированную, само собой.
Второе - переносить таблицу на более быстрый накопитель. Начиная от SSD и заканчивая зеркалом таблицы в памяти.]]> Akina Базы данных: SQL https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694548 Sun, 20 Nov 2016 18:49:07 +0000 UPDATE large table WHERE id in (1,2,3) https://forum.sources.ru/index.php?showtopic=409963&view=findpost&p=3694548 UPDATE `table` SET `data`=`data`+1 WHERE `id` IN (1, 10, 100, 5, 3, 6...)

За раз в множество ID включается где-то 150к чисел. И на 1 такой запрос уходит примерно 70 секунд. Но мне нужно обновлять минимум миллион строк в минуту. Подскажите куда копать. Я думал операции по primary key должны выполняться быстро]]> Dart_Sitius Базы данных: SQL