Основная проблема с производительностью вставки/обновления

Запуск базы данных MySQL и все таблицы InnoDB

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

В этом списке есть два запроса: вставка и обновление.

Сценарий вставки регистрирует просмотры страниц для пользователя. Чтобы сделать это более эффективным, мы будем писать вставку только один раз для пользователя в сеансе. Таким образом, мы сохраняем страницы, просмотренные в сеансе, и выполняем in_array при загрузке страницы. Если страницы нет в массиве, то пишем вставку.

Эта таблица содержит более 700 000 записей, единственным индексом которых является первичный ключ (id).

Вставка в эту таблицу выглядит так:

insert into page_views (user_id,page_name,created)
values ('4','Test Page','2013-08-13 10:44:21')

Этот запрос отображается в нашем журнале медленных запросов как требующий некоторого времени. Мой вопрос в том, как это можно сделать более эффективным. Я чувствую, что это одна из причин, по которой наша база данных работает медленнее.


У нас также есть запрос на обновление, который выполняется в таблице InnoDB с более чем 14 000 записей. Обновление происходит, когда пользователь впервые просматривает определенную запись, и мы устанавливаем поле под названием «просмотрено» = «ДА».

update test_table set viewed='YES' where id=55

Это обновление также отображается в журнале медленных запросов. Эта таблица «test_table» имеет около (5) разных индексов.


#

Вывод из журнала медленных запросов

Количество: 165 (0,35%) Время: 2252,210041 с всего, 13,649758 с в среднем, от 2,026723 до 313,311842 с макс (8,96%) 95% времени: 1181,480258 с всего, 7,573591 с от 9 до 4 в среднем, от 1,573591 с до 4 с 4, 23,026 ) : всего 12,722 мс, 77 в среднем, от 38 до 233 макс. (0,04 %) 95 % блокировки: всего 11,681 мс, 75 в среднем, от 38 до 84 макс. Отправлено строк: 0 в среднем, от 0 до 0 макс (0,00 %) 0 в среднем, от 0 до 0 макс. (0,00%) База данных: Пользователи: XXXXX@localhost: 100,00% (165) запросов, 99,76% (46921) всех пользователей

Аннотация запроса: SET timestamp=N; ВСТАВИТЬ В page_views (user_id, page_name, created) VALUES ('S', 'S', 'S')1;

Структура таблицы для page_views

id (int) первичный ключ имя_страницы (varchar(255)) дата и время создания

Каковы мои варианты ускорения простой вставки и обновления в очень больших таблицах?


person Gene Kelly    schedule 13.08.2013    source источник
comment
Вы должны опубликовать схему своей таблицы (выход SHOW CREATE TABLE tablename).   -  person Joshua Martell    schedule 13.08.2013
comment
Не могли бы вы предоставить больше информации о структуре таблицы (показать оператор создания таблицы) и о том, правильно ли настроен сервер для обработки innodb? innodb нужен хороший конфиг или это беда.   -  person Raymond Nijland    schedule 13.08.2013
comment
Если я вас правильно понял, ваше приложение использует очень много из этих двух утверждений, и те, которые вы нам показали, являются примерами. Это правильно? Можете ли вы показать нам EXPLAIN вывод этих запросов?   -  person O. Jones    schedule 13.08.2013
comment
EXPLAIN не работает в UPDATE.   -  person Gene Kelly    schedule 14.08.2013


Ответы (1)


Основываясь на огромном количестве строк в вашей таблице, необходимо регулярно добавлять/изменять строки в этих таблицах. Я бы предложил сначала выполнить следующий запрос и посмотреть время выполнения для упомянутых вами запросов:

проанализировать таблицу page_views;

проанализировать таблицу test_table;

Вышеупомянутые команды не займут много времени, должны выполняться за 5/10 секунд.

Если вы можете позволить себе немного больше времени обслуживания (зависит от размера стола):

оптимизировать таблицу page_views;

оптимизировать таблицу test_table;

Если вы видите прирост производительности, я также хотел бы сообщить, что вы можете настроить задание cron, которое выполняет ежедневный анализ и оптимизацию еженедельно/ежемесячно.

person Suresh Gautam    schedule 12.05.2014