I'm trying to determine what situations MySQL updates an index. Say I have the following table:
CREATE TABLE MyTable (
ID INT NOT NULL AUTO_INCREMENT,
MyIndexedColumn VARCHAR NOT NULL,
MyNonIndexedColumn VARCHAR,
PRIMARY KEY (ID),
INDEX MyNewIndex(MyIndexedColumn)
)
Then I run the following SQL to insert a row:
INSERT INTO MyTable (MyIndexedColumn, MyNonIndexedColumn)
VALUES ('MyTestValue', 'MyTestValue');
I understand that this query will add some sort of hash key to a B-Tree index in MySQL for the value 'MyTestValue'.
Now, if I run the following statement, will that force that B-Tree index to be updated, even if I haven't changed the value of the column?
UPDATE MyTable SET MyIndexedColumn = 'MyTestValue',
MyNonIndexedColumn = 'A New Value' WHERE ID = 1;
Is MySQL smart enough to determine that? Or by just making that column part of the update statement, am I telling MySQL that possibly something has changed, and it should do the work to update the index?
Right-click the index that you want to modify and then click Properties. In the Index Properties dialog box, make the desired changes. For example, you can add or remove a column from the index key, or change the setting of an index option.
Mostly we create index when creating table. Any column in creating table statement declared as PRIMARY KEY, KEY, UNIQUE or INDEX will be indexed automatically by MySQL. In addition, you can add indexes to the tables which has data.
An auto-updated column is automatically updated to the current timestamp when the value of any other column in the row is changed from its current value. An auto-updated column remains unchanged if all other columns are set to their current values.
For the single-table syntax, the UPDATE statement updates columns of existing rows in the named table with new values. The SET clause indicates which columns to modify and the values they should be given. Each value can be given as an expression, or the keyword DEFAULT to set a column explicitly to its default value.
Not only is MySQL smart enough to not update the index if the value hasn't changed, it is smart enough to not rewrite the column value with the same value.
I did some testing on this, with mysql 5.0.41, comparing updates against two identical innodb tables (7 cols, all integers), except that one table had 5 indexes (a couple of which were 2-column), and the other table had no indexes. (Each table had its primary key index, though.)
Here's what I ended up with (the table without indexes is A, the table with indexes is 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
I'm assuming that part of the reason the same/incremented value ones are faster is because I had to look up the row before doing the update, so it'd be cached in some form in mysql.
This all pretty much plays out what the others are saying, but gives some perspective on how much things are affected by the indexes. However, in the specific case Jim asked about, it looks like it might be as much as 50% slower.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With