Доброго времени суток. Вылезла следующая проблема. Есть таблица примерно на 5.5 миллионов записей. Как выяснилось, подавляющее большинство этих записей лишние и требуют удаления. По довольно сложному алгоритму эти записи определяются и создается скрипт на их удаление. Навскидку взят метод формирования списка запросов на удаление 1000 записей в каждом: Delete From T1 Where ID In (ID1, ID2, ... ID1000) - естественно по первичному ключу. Запустил это скрипт на относительно производительном линуксовом серваке - выполнение идет уже более получаса. Отсюда вопрос: можно ли как-то оптимизировать и ускорить этот процесс?

Ролг Хупин, вся операция - удаление 5.5 миллионов записей - заняла больше часа. Для промышленного сервера это в моем случае неприемлемо

К сожалению, этот вариант мне вряд ли подойдет. Несложно написать хранимую процедуру, но алгоритм подразумевает проверку каждой записи, сверку ее полей с полями предыдущей и решение, нужно ли ее удалять (при этом переписав некоторые поля в ту самую предыдущую запись). Программа на Дельфях работает часа полтора, вряд ли процедура с курсорами, обрабатывающими 5 миллионов записей отработает намного быстрее, но при этом клиентская программа берет записи частями и почти не нагружает сервер. В итоге по времени в самом лучшем случае выйдет так на так. Да и формирование временной таблицы на несколько миллионов записей (пусть даже и с одним полем) - тоже процесс не быстрый... Скорее всего, решение будет в написании другой клиентской программы, которая будет выполнять эти запросы по одному с интервалом в несколько секунд между ними. Это будет, конечно, гораздо дольше, но зато вряд ли сильно нагрузит сервер

PizzaPizza, вы невнимательно прочли мой первый пост. Алгоритм определения удаляемых записей тут ни при чем. Я просил совета именно по ускорению самого скрипта на удаление записей. Время на анализ данных и создание этого скрипта мне неважно - скрипт уже создан и пересоздать его при необходимости в более оптимальном варианте не составляет проблем. Мне нужен только конечный результат - максимально быстрое удаление уже найденных конкретных записей

Gluck99, если так оформлять пачки запросов, то что должно быть между ними? Или вообще отказаться от понятия пачек и выполнять все удаления подряд по одной записи?

Dimitry Sibiryakov, поэтому я формировал запросы на удаление сразу 1000 записей. Но вот тут знающие товарищи говорят, что это не есть правильно

Gluck99, у меня получилось. Как минимум, определение подлежащих удалению записей не завесило на лишних 30-40 минут промышленный сервак. Я, кажется, вполне понятно объяснил довольно простую вещь - в вашем варианте выигрыш в скорости при удалении записей компенсируется проигрышем за счет времени выполнения их обработки. В конечном варианте у меня минут 20 на удаленном клиенте - на столь нелюбимом вами паскале - формируется скрипт, обрабатывая записи по частям и, соответственно, довольно слабо, периодически и на короткие сроки нагружая сервер, и еще минут 20 этот скрипт на сервере выполняется. При этом в системные логи MySQL падает 5 тысяч запросов, а не 5 миллионов. Вы почему-то считаете свои критерии разработки программ единственно верными, а это не так. Мне важно выполнить задачу так, чтобы 15000 клиентов, которые в режиме 24х7 обращаются к базе, не зависли на лишних полчаса, поэтому для меня вполне приемлемо выполнить часть работы на удаленном клиенте, пусть даже общее время несколько возрастет. Для общего развития рекомендую провести следующий опыт: написать хранимую процедуру, в которой открыть курсор на чтение 5 000 000 записей из 10-15 полей каждая и просто сравнить каждое из этих полей со значением из предыдущей записи (это только часть моей задачи), а после этого примерно 9 из 10 записей удалить. Вряд ли вы сумеете меня убедить, что весь этот процесс даже на мощном и не очень нагруженном сервере займет менее получаса. Для того, чтобы судить о способе выполнения задачи, надо как минимум знать ее постановку и требования к реализации. Ни о том, ни о другом вы не имеете ни малейшего понятия, поэтому вы при всем желании не можете судить, правильно ли я эту задачу решаю или нет. Я задал конкретный вопрос - как ускорить удаление записей, зная их первичные ключи. Как я определяю эти записи - мое личное дело, и время их определения - как я уже писал - не входит в процесс ускорения задачи. Формировать запросы на удаление по одной записи вместо 1000-х пакетов - это вполне логичный совет, я попробую (хотя подозреваю, что падение в системный лог 5 000 000 запросов вместо 5 000 тоже будет грузить сервер), а мой способ определения этих записей меня вполне устраивает

Gluck99, вы неправильно истолковали эти признаки. У меня проблема именно такая, какую я описал. И проблема эта уже решена - данные удалены в течение вполне приемлемых сроков - удаление выполнено минут за 15-20. Вы не ответили на мой вопрос: сколько времени займет выполнение хранимой процедуры, которая курсором обойдет 5 миллионов записей? И насколько она загрузит сервер? Я вам уже в третий раз объясняю: ускорение самого удаление записей по вашему методу влечет за собой увеличение общего времени выполнения всей задачи, причем именно на сервере, что мне никак не было нужно. Я вынес обработку записей и формирование скрипта на клиент и нисколько не сомневаюсь, что был прав. Вот формирование этого самого скрипта может быть выполнено несколькими вариантами и я искал лучший. С чего вы взяли, что апдейт 5 миллионов записей, чтобы выставить ту самую пометку на удаление, чтобы потом удалить эти самые 5 миллионов по выставленной пометке, будет выполняться намного быстрее? Как по мне, то в совокупности в лучшем случае те же яйца, только в профиль. Как ни крути, запросов будет именно столько, сколько вышло у меня - никак не меньше. Либо 5 миллионов апдейтов по одной записи по первичному ключу, чтобы выставить ваши галочки, и потом одним запросом удалить все записи с галочками, либо 5 миллионов делитов тех же записей по первичному ключу. Либо - в моем случае - 5 тысяч запросов - что на выставление галочек у 1000 записей по условию ID In (), что на удаление тех же самых записей по тому же условию. Как бы вы не извращались с алгоритмом выбора нужных записей, все это не сократит количество запросов для их удаления. Ни от одного из них никуда не денешься. Поэтому в любом случае скрипт удаления записей на сервере выполнится быстрее, чем то же удаление плюс предварительная выборка этих записей, выполняемые в рамках одной хранимой процедуры. И кто вам сказал, что мой алгоритм поиска удаляемых записей уже максимально не облегчен? Вы видели его реализацию?

вадя, а вы отвечайте на вопрос, который был задан. Или не отвечайте, если неохота. Все очень просто

PizzaPizza, да, это разовая задача. И я не пробовал пока удалять записи любым способом. Выполнялся скрипт, состоящий их запросов вида Delete From `tbStockItemsLog` Where `ID` In (ID1, ID2, ... ID1000). Насколько я понимаю, там должно было быть порядка 5000 с небольшим таких запросов. Таблица создана таким скриптом:




Есть какие-то замечания? Что именно здесь "наклепано так, что нужно обратиться к специалисту по базам данных"? С удовольствием выслушаю любые замечания