Несколько запросов VS Сохраненная процедура

Question

У меня есть приложение , которое делает около 20000 ДАННЫХ ОПЕРАЦИЙ в час DATA-OPERATION имеет 30 параметров (для всех 10 запросов). Некоторые - это текст, некоторые - числовые. Некоторые текстовые параметры имеют длину 10000 символов.

Каждого DATA-OPERATION делает следующее:

• Одиночные ДАННЫЕ РАБОТЫ, вставки/обновление нескольких таблиц (около 10) в базе данных.
• Для каждого DATA-OPERATION я беру одно соединение,
• Затем я использую новый подготовленный оператор для каждого запроса в DATA-OPERATION.
• Подготовленный оператор закрывается каждый раз, когда выполняется запрос.
• Соединение используется повторно для всех 10 подготовленных операторов.
• Соединение закрывается при завершении операции DATA-OPERATION.

Теперь, чтобы выполнить эту DATA-РАБОТУ,

• 10 запросов, 10, подготовленный-заявление (создание, выполнение, близко), 1о N/W вызовов.
• 1 соединение (открыто, закрыто).

Я лично считаю, что если я создам хранимую процедуру из более чем 10 запросов, это будет лучший выбор.

В случае SP, DATA-OPERATION будет:

• 1 соединение, 1 вызываемая утверждение, 1 п/ш хит.

Я предложил это, но я сказал, что

• Это может быть больше времени, чем SQL-запросов.
• Он добавит дополнительную нагрузку на сервер БД.

Я все еще считаю, что SP - лучший выбор. Пожалуйста, дайте мне знать ваши материалы.

Бенчмаркинг - это вариант. Придется искать любые инструменты, которые могут помочь в этом. Также можно предложить уже имеющиеся тесты для такого рода проблем.

Answer 1

Любая рекомендация частично зависит от того, где находится сценарий, выполняющий запросы. Если скрипт, выполняющий запросы, находится на том же сервере, что и экземпляр MySQL, тогда вы не увидите такой большой разницы, но при выполнении запросов 200k по-прежнему будут небольшие накладные расходы по сравнению с 1 хранимой процедурой.

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

1. процедура, которая сочетает в себе 10 заявлений вы делаете каждую операцию в 1 вызов
2. процедуры, которая может итерацию через таблицу аргументов, используя CURSOR кормить в порядок 1

Ваших процесс будет равен

1. Заполнить таблицу аргументами, которые будут подаваться в процедуру 1 по процедуре 2
2. Процедура выполнения 2

Это обеспечит преимущества по производительности, поскольку нет необходимости подключаться к серверу MySQL 20000 * 10 раз. Хотя накладные расходы по запросу могут быть небольшими, миллисекунды складываются. Даже если сохранение составляет 0,1 мс на запрос, это еще 20 секунд.

Другим вариантом может быть изменение ваших запросов для выполнения всех операций 20k данных сразу (если это необходимо) путем настройки ваших 10 запросов для извлечения данных из таблицы базы данных, упомянутой выше. Ключом всего этого является получение аргументов, загружаемых в одну вставку пакета, а затем использование операторов на сервере MySQL в рамках процедуры для их обработки без дальнейших круговых переходов.