Когда 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 достаточно умным, чтобы это определить? Или просто сделав эту часть отчета об обновлении, я говорю MySQL, что, возможно, что-то изменилось, и он должен выполнить работу по обновлению индекса?

Answer 1

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

Ряды совпадений: 1, Ряды Обновлено: 0

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

Answer 2

При выполнении UPDATE MySQL сообщает количество совпадающих строк и число изменилось. Запуск пример запроса дает выход:

Query OK, 0 затронутых строк (0,00 сек) Ряды совпадающая: 1 Изменено: 0 Предупреждения: 0

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

Answer 3

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

Answer 4

Я провел некоторое тестирование на этом с помощью mysql 5.0.41, сравнивая обновления с двумя идентичными таблицами innodb (7 cols, все целые числа), за исключением того, что в одной таблице было 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% медленнее.