Do mysql update queries benefit from an index?

Question

I have a table which I do mainly updates and I\'m wondering if update queries would benefit from having an index on the where column and the updated column or an index on ju

Answer 1

Not a straight forward answer for this one. So here goes.

UPDATE table SET ColumnA = 'something' 

if an index exists on ColumnA then you will have a slight performance hit as there will be two write operations for each row. First the data in the table and then the write for the index update.
You can even have several indexes that each have ColumnA as part of the index which mean you will have several writes in addition to the table row. You can see how having more than a few indexes can start to really slow your updates down.
But if ColumnA is not indexed at all then it will be a single write for each row only.

UPDATE table SET ColumnA = 'something' WHERE ColumnB = 'something else'

For this query if an index exists on ColumnB and not on ColumnA, it will be very fast to locate the record (called a seek) and a single write to update, and as the index doesn't care about columnA, it wont need updating.
But if you index ColumnA and not ColumnB, You will read every row in the table first (called a scan and normally a bad thing) which while a read is faster than a write it is still very slow, then it will write to the table and then another write for the index. Basically the slowest way of doing things.

DELETE table WHERE ColumnB = 'somethingelse'

Now if you have an index on any column in this table two writes, delete from table and a update/delete of the record in the index.
Again if ColumnB is not indexed, you will scan the table then delete the row(s) from the table and update indexes if any.

INSERT INTO table (ColumnA, ColumnB) VALUES ('something','something else')

If no indexes exist, a single write to the table and it's done.
Again, if indexes do exist, then an extra write for each one.

I haven't mentioned the primary key unique constraints, because you really cant get around them when you need a primary key, but every record must be checked to see if something already exists with that key before insert. Which will be a fast primary key index seek, but nevertheless, its another step in the process. The less steps the faster it will be.

Now back to yours, Basically, if you need to update a specific record, an index will help you locate that record faster than scanning the entire table. The the time saved to locate the record will be much more then the time lost updating the indexes. If you are only inserting and never reading, then indexes will slow you down. It becomes a balance thing. If you need to read specific records, then an index will help immensely. But the more indexes, the slower the writes get.