колонка timestamp индексации mysql, которая часто обновляется

Question

Я использую mysql (innoDB). У меня есть таблица больших пользователей с этими столбцами: user_id, last_action_time. User_id - это уникальный первичный ключ. Таблица имеет около 5 миллионов строк.

+------------------+-----------+------+-----+---------+-------+ 
| Field   | Type  | Null | Key | Default | Extra | 
+------------------+-----------+------+-----+---------+-------+ 
| user_id   | int(11) | NO |  | NULL |  | 
| last_action_time | timestamp | YES |  | NULL |  | 
+------------------+-----------+------+-----+---------+-------+ 

Всякий раз, когда пользователь делает действие на сайте, я обновляю метку времени в столбце last_action_time. Для системы Back-office мне нужно показать 30 последних пользователей, совершивших действие на сайте. Что-то вроде этого:

SELECT user_id,last_action_time FROM user_table ORDER BY last_action_time DESC LIMIT 30 

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

Answer 1

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

Если вы стесняетесь создать индекс или не просто сравните частоту своих запросов с их эффективностью.

• обновление: каждая обновленная строка, вы обновите один указатель в индексе. Снижение эффективности будет очень низким, если ваш индекс находится в памяти (и это, безусловно, есть, если вы не используете очень мало немного памяти).
• выберите: ваш запрос выбора должен будет выполнить полное сканирование таблицы вместо чтения индекса. Проверьте, насколько вы ускорите запрос. Это может быть в 100 раз быстрее или на 1000 раз быстрее, в зависимости от размера таблицы.

Теперь к решению:

• очень небольшой штраф для запроса обновления не будет весить из огромной пользы для выбора запроса. Подумайте также о других проблемах с полным сканированием таблицы (недействительность кэша).
• Если у вас есть 1 выбор запроса для 1000 или 10 000 обновлений, вы можете начать думать о том, чтобы удалить индекс. Если вы выбираете более часто, не стесняйтесь.