спосіб запобігти запитам очікування блокування рівня таблиці

Ми зіткнулися з проблемою після переміщення бази даних нашого клієнта на додатковий сервер. Це повинно було мати позитивний вплив на продуктивність сайту, але існує проблема з блокуванням таблиці в MyISAM. (Я чув про використання InnoDB замість MyISAM, але ми не можемо змінити двигун найближчим часом).
Ми можемо помітити його на запит на оновлення, який виконується, коли модератор активує коментар до статті. Це процес:

• оновлення-запит обробляється SET status = 1 WHERE id = 5(індекс встановлюється)
• кешовані файли сторінки видаляються

У цей момент вся сторінка стає повільною. Сама база даних зайнята хвилин. Я кілька разів вибирав список процесів і бачив близько 60 записів різних селекційних запитів, які були в штаті, очікуючи блокування рівня таблиці .

1. Я не розумію, чому це оновлення в таблиці article_commentsможе вплинути на оператори select для таблиці, articleщоб чекати блокування рівня таблиці. У списку процесів майже всі запити очікування були з цієї таблиці. Я читав про те, що оновлення / вставки вважають за краще вибирати і що це може спричинити такі проблеми, але сама таблиця статей не оновлюється, коли коментарі стають активованими, тому вибір не повинен чекати. Невже я це зрозумів?
2. Чи є щось, крім того, щоб змінити InnoDB, щоб запобігти такій поведінці або принаймні для покращення балансу? Мене дуже дратує те, що ця проблема не з’явилася перед переміщенням бази даних на новий сервер. Я думаю, що є якась неправильна конфігурація, але я не знаю, як ідентифікувати.

MyISAM Storage Engine суто відомий тим, що виконує блокування повних таблиць для будь-яких DML (ВСТАВКИ, ОНОВЛЕННЯ, ВИДАЛЕННЯ). InnoDB напевно вирішить це питання в довгостроковій перспективі.

Я писав про плюси і мінуси використання MyISAM проти InnoDB

• InnoDB проти MyISAM з багатьма показниками (05 липня 2012 р.)
• Що швидше, InnoDB або MyISAM? (03 травня 2012 р.)
• Будь-які проблеми з переходом від MyISAM до InnoDB? (09 січня 2012 р.)
• Чи слід використовувати оптимізацію цих таблиць для зберігання даних, окрім MyISAM, або я повинен отримати кращі диски? (07 жовтня 2011 р.)
• Переваги блокування рівня таблиці (14 вересня 2011 р.)
• Які основні відмінності між InnoDB та MyISAM? (14 квітня 2011 р.)

Що стосується вашого поточного питання, то тут можливий сценарій:

• articleі article_commentsє обома таблицями MyISAM
• article_commentsмає один або декілька індексів, statusяк стовпець
• Оновлення сторінок індексів для article_commentsкешується в буфері MyISAM Key (розмір key_buffer_size ), в результаті чого старі індексні сторінки виходять із ключа буфера MyISAM
• У вас є SELECT запити, які виконують JOIN між articleіarticle_comments

У моїй запропонованої сценарії ВИБИРАЄ проти articleтаблиці може бути проведена по порівнянні з , дозволяючи запис з - за того , щоб чекати , article_commentsщоб бути вільними від будь-якого DML (в цьому випадку UPDATE)

У цей момент вся сторінка стає повільною. Сама база даних зайнята хвилин.

Пахне, як у вас великий Query_cache?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

У виробничих системах з великою кількістю записів ви також можете вимкнути кеш запитів.

Всі записи в query_cache для даної таблиці видаляється при будь- записи відбувається в цю таблицю. Чим більше КК, тим повільніше це завдання.

MyISAM використовує блокування "рівень таблиці". Читання та запис не може відбуватися одночасно (за тією ж таблицею). Сирий, але ефективний.