Как проверить / обновить столбцы в базе данных около миллиона строк?

Question

Как проверить / обновить столбцы в базе данных около миллиона строк?

0

У меня есть база данных MYSQL, которая содержит около 1 миллиона (1 000 000) строк, я хочу проверить все строки и обновить некоторые в соответствии с условием. Так, например, я запускаю инструкцию SQL следующим образом:

select messageid from messages where messageid !=""

Затем я извлекаю все идентификаторы и сохраняю их в переменной:

$existMessages;

Затем я генерирую строку из 4 символов 0-9a-z:

function generateRandomString($length = 4) {
    return substr(str_shuffle(str_repeat($y='0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ', ceil($length/strlen($y)) )),1,$length);
}

Затем я обновляю существующие идентификаторы сгенерированными строками, после проверки уникальности сгенерированных идентификаторов.

Этот процесс становится медленнее и занимает весь процессор по мере увеличения рядов.

Есть ли лучший способ сделать это? Как использовать SQL-инструкции непосредственно в MYSQL? Или что делать?

kevin 08 апр. 2018, в 19:28

Источник

0

Вы должны использовать процедуру хранения MySQL
TIGER 08 апр. 2018, в 16:50
0

Возможно, это единовременная вещь, чтобы заставить их всех иметь это, и где бы они ни были вставлены, также должны быть добавлены уникальные идентификаторы? Тогда тебе не пришлось бы это делать?
James 08 апр. 2018, в 17:17
0

@James, да в общем это должно быть то же самое, но это особый случай, и мне нужно время от времени обновлять этот столбец с уникальным случайным значением
kevin 08 апр. 2018, в 17:23
0

«время от времени», но если бы это было в коде INSERT, вам не нужно было бы делать это снова? Вставка уже сделала бы это
James 08 апр. 2018, в 17:24
0

Всего миллион, у меня была таблица с 120 миллионами, затем мы переместили ее в MongoDB, в основном потому, что она потребляла более 80 ГБ HD и 30 ГБ или оперативной памяти, а не то, что MongoDB справляется с этим лучше. Миллион - это маленький картофель, у меня сейчас 2 стола с чуть более миллиона :-)
ArtisticPhoenix 08 апр. 2018, в 18:03
1

Я не понимаю цель этого запроса: select messageid from messages where messageid !="" Вы выбираете идентификатор, по идентификатору, когда знаете, что это за идентификатор? Может быть, это просто пример, но он плохой, поскольку есть способы оптимизировать выборки, но нам нужен реальный выбор. Например, если у вас есть уникальное поле, и вы хотите вставить данные, быстрее поймать ошибки дублирующегося ключа, чем сделать выбор и вставку, потому что вам не нужно выполнять 1 из запросов.
ArtisticPhoenix 08 апр. 2018, в 18:06
0

@James, это потому, что это не идентификатор автоинкремента столбца, есть id и messageid, id это автоинкремент, где messageid является уникальной строкой, например, когда вы хотите создать ссылку активации, чтобы создать случайный ключ
kevin 08 апр. 2018, в 18:24
0

@ArtisticPhoenix, некоторые строки уже содержат случайную строку, теперь есть новые созданные строки, поэтому я выбираю все идентификаторы, чтобы убедиться, что идентификаторы не дублируются
kevin 08 апр. 2018, в 18:26
0

Может быть, я неправильно понимаю вас, или вы меня. Я буду ясно, как это возможно. Вы вставляете строку, в этой строке находится поле messageid . Позже вы приходите и в том же ряду в messageid вы обновляете данные. Если это для каких-либо / всех строк, где messageid пуст, то это должно быть установлено при первой вставке. И / или всякий раз, когда какой-либо скрипт очищает это поле, он должен вызывать скрипт, из которого вы генерируете случайный код, и затем обновлять его этим. то есть всякий раз, когда ЛЮБОЙ скрипт выполняет действия с этой таблицей и этим полем, если он будет пустым, тогда установите объект, а не устанавливайте его пустым, а затем исправьте это :)
James 08 апр. 2018, в 18:30
0

Какой драйвер базы данных, вы используете, MySQL или PDO, вы пытались использовать небуферизованные запросы для выбора? Обычно это будет компромисс между временем и памятью. for your comment я не понимаю, почему вместо удаления и вставки у вас есть пустые идентификаторы, обновления выполняются медленнее, чем любой из этих 2.
ArtisticPhoenix 08 апр. 2018, в 18:30
0

Похоже, у вас проблемы с дизайном, поскольку обновление идентификаторов действительно нечасто. Это может быть однократная операция по устранению недостатка, но она не требуется для технического обслуживания. Возможно, TRIGGER, который действует на INSERT, лучше исправить неправильные идентификаторы.
Luis Muñoz 08 апр. 2018, в 18:41
0

Кажется, я не проясняю, столбец messageid не является идентификатором строки, я не хочу вставлять туда цифры, я не упорядочиваю таблицу с этим столбцом, для этой цели есть столбец с именем id
kevin 08 апр. 2018, в 19:44
0

@ArtisticPhoenix, я использую PDO
kevin 08 апр. 2018, в 19:44
0

Хорошо, но вы все еще не предоставили мне достаточно информации, каков запрос для этого. Then I update the existing IDs with the generated strings . Является ли идентификатор уникальным и т. Д. Если у вас миллион строк, есть большая вероятность, что ваш случайный случай сгенерирует одну и ту же строку более одного раза, особенно с $length = 4 или (62 * 62 * 62 * 62 = 14,776,336)
ArtisticPhoenix 08 апр. 2018, в 20:02
0

так что вы видите, что у вас есть шанс 1 к 14, когда у вас там 1 миллион строк. Это ухудшается каждый раз, когда вы добавляете строку.
ArtisticPhoenix 08 апр. 2018, в 20:08

Показать ещё 13 комментариев

Теги:

php

mysql

sql

performance

pdo

4 ответа

Ещё вопросы

Вы должны использовать процедуру хранения MySQL
Возможно, это единовременная вещь, чтобы заставить их всех иметь это, и где бы они ни были вставлены, также должны быть добавлены уникальные идентификаторы? Тогда тебе не пришлось бы это делать?
@James, да в общем это должно быть то же самое, но это особый случай, и мне нужно время от времени обновлять этот столбец с уникальным случайным значением
«время от времени», но если бы это было в коде INSERT, вам не нужно было бы делать это снова? Вставка уже сделала бы это
Всего миллион, у меня была таблица с 120 миллионами, затем мы переместили ее в MongoDB, в основном потому, что она потребляла более 80 ГБ HD и 30 ГБ или оперативной памяти, а не то, что MongoDB справляется с этим лучше. Миллион - это маленький картофель, у меня сейчас 2 стола с чуть более миллиона :-)
Я не понимаю цель этого запроса: select messageid from messages where messageid !="" Вы выбираете идентификатор, по идентификатору, когда знаете, что это за идентификатор? Может быть, это просто пример, но он плохой, поскольку есть способы оптимизировать выборки, но нам нужен реальный выбор. Например, если у вас есть уникальное поле, и вы хотите вставить данные, быстрее поймать ошибки дублирующегося ключа, чем сделать выбор и вставку, потому что вам не нужно выполнять 1 из запросов.
@James, это потому, что это не идентификатор автоинкремента столбца, есть id и messageid, id это автоинкремент, где messageid является уникальной строкой, например, когда вы хотите создать ссылку активации, чтобы создать случайный ключ
@ArtisticPhoenix, некоторые строки уже содержат случайную строку, теперь есть новые созданные строки, поэтому я выбираю все идентификаторы, чтобы убедиться, что идентификаторы не дублируются
Может быть, я неправильно понимаю вас, или вы меня. Я буду ясно, как это возможно. Вы вставляете строку, в этой строке находится поле messageid . Позже вы приходите и в том же ряду в messageid вы обновляете данные. Если это для каких-либо / всех строк, где messageid пуст, то это должно быть установлено при первой вставке. И / или всякий раз, когда какой-либо скрипт очищает это поле, он должен вызывать скрипт, из которого вы генерируете случайный код, и затем обновлять его этим. то есть всякий раз, когда ЛЮБОЙ скрипт выполняет действия с этой таблицей и этим полем, если он будет пустым, тогда установите объект, а не устанавливайте его пустым, а затем исправьте это :)
Какой драйвер базы данных, вы используете, MySQL или PDO, вы пытались использовать небуферизованные запросы для выбора? Обычно это будет компромисс между временем и памятью. for your comment я не понимаю, почему вместо удаления и вставки у вас есть пустые идентификаторы, обновления выполняются медленнее, чем любой из этих 2.
Похоже, у вас проблемы с дизайном, поскольку обновление идентификаторов действительно нечасто. Это может быть однократная операция по устранению недостатка, но она не требуется для технического обслуживания. Возможно, TRIGGER, который действует на INSERT, лучше исправить неправильные идентификаторы.
Кажется, я не проясняю, столбец messageid не является идентификатором строки, я не хочу вставлять туда цифры, я не упорядочиваю таблицу с этим столбцом, для этой цели есть столбец с именем id
Хорошо, но вы все еще не предоставили мне достаточно информации, каков запрос для этого. Then I update the existing IDs with the generated strings . Является ли идентификатор уникальным и т. Д. Если у вас миллион строк, есть большая вероятность, что ваш случайный случай сгенерирует одну и ту же строку более одного раза, особенно с $length = 4 или (62 * 62 * 62 * 62 = 14,776,336)
так что вы видите, что у вас есть шанс 1 к 14, когда у вас там 1 миллион строк. Это ухудшается каждый раз, когда вы добавляете строку.

Rick James · Answer 1 · 2018-04-09T17-34-00.000Z

Я устраню необходимость в "проверке" и сделаю это быстрее.

Есть не более миллиона таких 4-символьных строк. Таким образом, будет некорректное количество дубликатов, если вы "произвольно" их генерируете.

Вместо этого я рекомендую

Создайте все из них (или миллион из них)
Перемешать их
Примените их к своему столу.
- CONV(x, 10, 36) генерирует значение base-36 (0-9A-Z) из x. Но, может быть, лучше...
- Создайте таблицу с 36 строками 0..9, a..z.
- CROSS JOIN присоединяйтесь к нему 4 раза, чтобы сгенерировать все 36 ^ 4 комбо.
- ORDER BY RAND() будет перемешать их, не приводя к дублированию.
- Многостраничный UPDATE позволит вам скопировать строку из 4-х символов из одной таблицы в другую.

âńōŋŷXmoůŜ · Answer 2 · 2018-04-08T16-24-00.000Z

Вы можете использовать предложение ниже обновления. Это позволит выбрать 4 случайных буквы и цифры для нижнего и верхнего регистров и 0-9.

update table_name cross join (select 
@chars:='1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIKLMNOPQRSTUVWXYZ') tab
set messageid = concat(substring(@chars, floor(rand()*61) + 1, 1),
               substring(@chars, floor(rand()*61) + 1, 1),
               substring(@chars, floor(rand()*61) + 1, 1),
              substring(@chars, floor(rand()*61) + 1, 1)
          )
where messageid !="";

Sandesh Gupta · Answer 3 · 2018-04-08T15-23-00.000Z

Сначала вы должны указать unique or primary ограничение для столбца, который вы хотите быть уникальным.

После этого вы можете выполнить команду update

UPDATE TABLE_NAME SET COLMUN_NAME=generateRandomString() WHERE messageid !="";

Matthew Knight · Answer 4 · 2018-04-08T14-30-00.000Z

Вы можете напрямую использовать SQL и создать простой хеш, основанный на некоторых данных в строке, например:

UPDATE table_name SET messageid = MD5(messageid) WHERE messageid !="";

Возможно, вы захотите сделать это партиями, поэтому добавьте LIMIT в оператор, т.е. LIMIT 0,1000, чтобы сделать кучу за раз.

«Этот процесс замедляется и занимает весь процессор по мере увеличения строк». qeuries с LIMIT также станут медленнее, если будут использованы большие числа смещений.