Як визначити оптимальний sort_buffer_size?

Я читаю із зразкового файлу конфігурації, який говорить наступне:

# Sort buffer is used to perform sorts for some ORDER BY and GROUP BY
# queries. If sorted data does not fit into the sort buffer, a disk
# based merge sort is used instead - See the "Sort_merge_passes"
# status variable. Allocated per thread if sort is needed.

У мене є кілька запитів, які використовують fileort. Як визначити, який розмір буфера, який мені потрібен для безперебійного виконання запитів, не потрапляючи на диск?

Є лише одна змінна статусу, яка дбає про sort_buffer_size . Це те, що ви маєте в повідомленні ще в питанні: Sort_merge_passes . Документація MySQL говорить:

Sort_merge_passes: кількість проходів злиття, які повинен був зробити алгоритм сортування. Якщо це значення велике, слід розглянути можливість збільшення значення системної змінної sort_buffer_size .

Будь ласка, пам’ятайте про одне про sort_buffer_size

Якщо ви бачите багато параметрів Sort_merge_passes в секунду на виході SHOW GLOBAL STATUS, ви можете розглянути можливість збільшення значення sort_buffer_size для прискорення операцій ЗАМОВЛЕННЯ ПО ГРУПІ або ГРУПІ, які неможливо покращити за допомогою оптимізації запитів або покращеної індексації

Хоча підвищення sort_buffer_sizeможе допомогти запитам з GROUP BYs і ORDER BYs, вам краще покращити запити, які ви можете вдосконалити, та додавши індекси, які можуть використовуватися Оптимізатором запитів.

Залишається питання: Як перевірити Sort_merge_passes ???

Скористайтеся цим кодом, щоб перевірити, скільки сортувальних_посадок трапилося за останні 5 хвилин. Він також обчислює параметри Sort_merge_passes на годину.

SET @SleepTime = 300;
SELECT variable_value INTO @SMP1
FROM information_schema.global_status WHERE variable_name = 'Sort_merge_passes';
SELECT SLEEP(@SleepTime) INTO @x;
SELECT variable_value INTO @SMP2
FROM information_schema.global_status WHERE variable_name = 'Sort_merge_passes';
SET @SMP = @SMP2 - @SMP1;
SET @SMP_RATE = @SMP * 3600 / @SleepTime;
SELECT @SMP,@SMP_RATE;

Якщо ви вважаєте, що параметри Sort_merge_passes і коефіцієнт занадто високі, тоді сміливо збільшуйте sort_buffer_size . Припустимо, ви хочете підвищити до 4М. Ви б запустили це:

mysql> SET GLOBAL sort_buffer_size = 1024 * 1024 * 4;

Потім ви додасте це до my.cnf

[mysqld]
sort_buffer_size = 4M

Ви періодично запускаєте код, щоб перевірити наявність інших шипів Sort_merge_passes .

Не потрібно змінювати розмір sort_buffer_size за замовчуванням. Ви неправильно розумієте, що це використання на основі питання. Спершу слід вивчити SQL, щоб побачити, чи зможете ви його настроїти та задовольнити умови ЗАМОВЛЕННЯ ПО ГРУПІ / ГРУПІ за допомогою індексу. Це, як правило, складений індекс.

Далі: http://www.xaprb.com/blog/2010/05/09/how-to-tune-mysqls-sort_buffer_size/

Посібник у посібнику (5,0-5,5) є

Якщо ви бачите багато параметрів Sort_merge_passes в секунду на виході SHOW GLOBAL STATUS, ви можете розглянути можливість збільшення значення sort_buffer_size для прискорення операцій ORDER BY або GROUP BY, які не вдається покращити за допомогою оптимізації запитів або покращеної індексації. Весь буфер виділяється, навіть якщо він не весь необхідний, тому встановлення його більше, ніж потрібно в усьому світі, сповільнить більшість запитів, що сортуються. Найкраще збільшувати його як налаштування сеансу, і лише для сеансів, які потребують більшого розміру. В Linux є порогові значення в 256 КБ і 2 МБ, де більші значення можуть суттєво уповільнити розподіл пам’яті, тому вам слід подумати про те, щоб залишитися нижче одного з цих значень. Експериментуйте, щоб знайти найкраще співвідношення вашої навантаження.

З 5.6 далі формулювання вказує на те, що оптимізатор може вибрати значення для запиту і що сервер може розширити буфер до межі. Це зменшує занадто високу вартість встановлення значення. Отже, це здається, що ви можете захотіти бути консервативним, нижчим, ніж за замовчуванням (як це роблять файли cnf) для випусків під 5.6.4, але можете дозволити собі мати більш високу межу, скажімо, за замовчуванням 2 Мб або навіть більше, ніж 5,6. 4, оскільки повна сума не розподіляється сліпо.

Як і в MySQL 5.6.4, оптимізатор намагається визначити, скільки місця потрібно, але може виділити більше, до межі.

Найкращий спосіб визначити оптимальний sort_buffer_size- це його порівняння.

Як? Як @RolandoMySQLDBA сказав, що перевірка Sort_merge_passesможе бути корисною, але це не єдиний фактор, який впливає на продуктивність. Ви повинні бути обережними, коли збільшуєте sort_buffer_size.

У документі сказано, що

В Linux є порогові значення в 256 КБ і 2 МБ, де більші значення можуть суттєво уповільнити розподіл пам’яті, тому вам слід подумати про те, щоб залишитися нижче одного з цих значень.

Існує пост про тестування, який робить висновок про це

sort_merge_passesне такі вже й погані. Встановлення вашого sort_buffer_sizeдостатньо великого, щоб було нуля, sort_merge_passesможе бути не оптимальним.

Коли я тестував, я також отримую подібний результат.

В ідеалі, найкраще було б уникнути ситуації, яка вам потрібна для оптимізації sort_buffer_size. Як? Цей документ ORDER BY Optimization може допомогти вам зрозуміти, як все працює під кришкою.

"mysql> SET GLOBAL sort_buffer_size = 1024 * 1024 * 4;" це поганий спосіб розмістити в 4м розмір буфера сортування, тобто розмір буфера сортування має 4 Гб використання

"mysql> SET GLOBAL sort_buffer_size = 1024 * 4;"

Якщо я був вашим, я не намагаюся змінити розмір короткого буфера, це хороший спосіб зробити збій вашого сервера та відправити на продуктивність сміття. Краще спробуйте зробити кращі квери.