Wiele zapytań Procedura przechowywana VS

Question

Mam aplikację , która wykonuje około 20000 OPERACJI DANYCH na godzinę DATA-OPERATION ma łącznie 30 parametrów (dla wszystkich 10 zapytań). Niektóre są tekstem, inne są numeryczne. Niektóre parametry tekstowe są tak długie, jak 10000 znaków.

Każdy DANYCH OBSŁUGA jest następujący:

• Pojedyncza DANYCH OBSŁUGA wstawia/aktualizacje wielu tabel (około 10) w bazie danych.
• Dla każdej OPERACJI DANYCH, biorę jedno połączenie,
• Następnie używam nowego przygotowanego wyciągu dla każdego zapytania w DZIAŁANIU DANYCH.
• Przygotowana instrukcja jest zamykana przy każdym wykonaniu zapytania.
• Połączenie jest ponownie wykorzystywane dla wszystkich 10 przygotowanych wyciągów.
• Połączenie zostaje zamknięte po zakończeniu OBSŁUGI DANYCH.

teraz, aby wykonać te dane-operation,

• 10 pytań, 10-przygotowane oświadczenie (tworzenie, wykonywanie, w pobliżu), 1o n/w połączeń.
• 1 połączenie (otwórz, zamknij).

Osobiście uważam, że jeśli utworzę procedurę składowaną z ponad 10 zapytań, będzie to lepszy wybór.

W przypadku SP, DANYCH operacja będzie mieć:

• 1 połączenie, 1 wywoływalnym oświadczenie, 1 n/w przeboju.

zasugerowałem, ale powiedziano mi, że

• To może być bardziej czasochłonne niż zapytań SQL.
• Wprowadzi dodatkowe obciążenie na serwerze DB.

Nadal uważam, że SP to lepszy wybór. Proszę podać mi swoje dane wejściowe.

Benchmarking jest opcją. Będzie musiał przeszukać wszelkie narzędzia, które mogą w tym pomóc. Także każdy może zaproponować już dostępne testy porównawcze dla tego rodzaju problemu.

Answer 1

Każda rekomendacja zależy częściowo od miejsca, w którym znajduje się skrypt wykonujący kwerendy. Jeśli skrypt wykonujący kwerendy znajduje się na tym samym serwerze co instancja MySQL, nie zobaczysz tak dużej różnicy, ale nadal będzie mały narzut w wykonywaniu kwerend 200k w porównaniu do 1 procedury składowanej.

Moja rada byłaby jednak sposobem zrobienia tego jako procedury przechowywanej. Potrzebowałbyś może kilku procedur.

1. procedurę, która łączy w sobie 10 Skonsolidowane robisz per-pracy na 1 wezwanie
2. procedurę, która może iteracyjne nad tablicę argumentów używając CURSOR karmić w procedurze 1

Twój Proces ten będzie

1. Wypełnij tabelę z argumentami, które zostaną wprowadzone do procedury 1 według procedury 2
2. Wykonanie procedury 2

To przyniesie korzyści wydajnościowe, ponieważ nie ma potrzeby łączenia się z serwerem MySQL 20000 * 10 razy. Podczas gdy narzut na żądanie może być mały, należy dodać milisekundy. Nawet jeśli oszczędność wynosi 0,1ms na żądanie, to wciąż 20 sekund zapisane.

Inną opcją może być modyfikowanie żądań użytkownika, aby wykonać wszystkie operacje danych 20k na raz (jeśli to możliwe) poprzez dostosowanie 10 zapytań w celu pobrania danych z tabeli bazy danych wspomnianej powyżej. Kluczem do tego wszystkiego jest załadowanie argumentów do pojedynczego wsadu wsadowego, a następnie użycie instrukcji na serwerze MySQL w ramach procedury przetwarzania ich bez dalszych podróży w obie strony.