- Стоит ли добавлять индекс в быстро меняющийся столбец, такой как "lastUpdatedOn"?
- Как рассчитать компромисс ?
- Может ли кто-нибудь указать мне на официальную документацию о том, когда и как MySQL выполняет исправления при вставке строк и обновлениях индексированного столбца.
0
Наличие индекса, включающего "быстро меняющийся столбец", является компромиссом.
Один UPDATE необходимо удалить одну запись в индексе и добавить новую запись в другом месте индекса.
С другой стороны, индекс может значительно ускориться из - за индекса.
Пожалуйста, приведите конкретный пример, чтобы мы могли продолжить обсуждение компромиссов.
Регулярные не-UNIQUE индексы (в отличие от FULLTEXT и SPATIAL) поддерживаются таким образом:
В пуле буферов есть "буфер изменений" (qv), который поддерживает обновления индекса, которые еще не были записаны на диск.
Когда а DELETE в этом случае в буфер изменений добавляется запись, указывающая, что запись индекса необходимо удалить.
Для UPDATE возможно, потребуется внести в ЦБ две записи.
Когда а SELECT использует такой индекс, он проверяет как CB, так и реальное, на диске, BTree для индекса. Это BTree кэшируется (блок за блоком) в пуле буферов. (Блок размером 16 КБ может содержать сотни записей.)
CB сбрасывается на диск "в фоновом режиме" или "по мере необходимости". Это включает в себя извлечение блока индекса (если он еще не кэширован), обновление некоторых записей (удаление и/или добавление) и запись обратно на диск. Как чтение, так и запись кэшируются в пуле буферов, поэтому любой или ни один из них не может быть физическим вводом-выводом.
MySQL не "перестраивает" обычный индекс ("переиндексирует"), кроме как с помощью определенных ALTERs или OPTIMIZE. То есть все изменения вносятся на лету. Действие ЦБ прозрачно для пользователя.