Когда MySQL пытается обновить индекс для столбца?

Question

Я пытаюсь определить, в каких ситуациях MySQL обновляет индекс. Скажем, у меня есть следующая таблица:

CREATE TABLE MyTable (
  ID INT NOT NULL AUTO_INCREMENT,
  MyIndexedColumn VARCHAR NOT NULL,
  MyNonIndexedColumn VARCHAR,
  PRIMARY KEY (ID),
  INDEX MyNewIndex(MyIndexedColumn)
)

Затем я запускаю следующий SQL для вставки строки:

INSERT INTO MyTable (MyIndexedColumn, MyNonIndexedColumn) 
VALUES ('MyTestValue', 'MyTestValue');

Я понимаю, что этот запрос добавит некоторый хэш-ключ к индексу B-Tree в MySQL для значения 'MyTestValue'.

Теперь, если я выполню следующее утверждение, заставит ли это индекс B-Tree обновиться, даже если я не изменил значение столбца?

UPDATE MyTable SET MyIndexedColumn = 'MyTestValue', 
MyNonIndexedColumn = 'A New Value' WHERE ID = 1;

Достаточно ли умен MySQL, чтобы это определить? Или, просто сделав этот столбец частью оператора update, я сообщаю MySQL, что, возможно, что-то изменилось, и он должен выполнить работу по обновлению индекса?

Answer 1

Я провел некоторое тестирование на этом, с mysql 5.0.41, сравнивая обновления с двумя идентичными таблицами innodb (7 столбцов, все целые числа), за исключением того, что в одной таблице было 5 индексов (пара из которых состояла из 2 столбцов), и другая таблица не имела индексов. (У каждой таблицы был индекс первичного ключа.)

Вот что я закончил (таблица без индексов - A, таблица с индексами - B):

10k updates of an indexed column with a new value:
A:  76.8 seconds
B: 126.7 seconds

10k updates of a non-indexed column with a new value:
A: 27.6 seconds
B: 22.0 seconds

10k updates of a random column with its same value:
A: 1.4 seconds
B: 1.2 seconds

10k updates of a random column with an incremented value:
A: 12.2 seconds
B: 50.0 seconds

10k updates of an indexed column=>same value, non-indexed column=>new value:
A:  7.0 seconds
B: 10.5 seconds

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

Все это в значительной степени воспроизводит то, что говорят другие, но дает некоторое представление о том, насколько на индексы повлияли некоторые вещи. Однако в конкретном случае, о котором спрашивал Джим, похоже, что это может быть на 50% медленнее.

Answer 2

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

Answer 3

Если вы выполните этот запрос в клиенте MySQL, вы увидите что-то вроде

Строк соответствует: 1, Строк обновлено: 0

Так что MySQL определенно знает, когда строка изменилась или нет - я бы предположил, что они достаточно умны, чтобы не обновлять индекс оттуда.

Answer 4

Когда вы выполняете UPDATE, MySQL сообщает о количестве совпадений строк и изменении количества. Выполнение вашего примера запроса дает вывод:

Запрос в порядке, затронуто 0 строк (0,00 с) Количество подходящих строк: 1 Изменено: 0 Предупреждений: 0

Я был бы очень удивлен, если бы MySQL не использовал эту информацию для определения необходимости обновления индекса.