Understanding multiple indexes with MySQL (and performance) I have a "phones" table with around 120 000 records, it contains phone_id, phone_number, phone_user_name, phone_last_contacted, etc.

The phone_id is index and looks like: 1,2,3,4 ... 120 000.

But I often update different fields like "phone_last_contacted":

UPDATE phones SET phone_last_contacted = '01-01-2013' WHERE phone_number = '+123456789'

The "slow query" log says that query read many records before finding the right one to update;

Would it be a performance upgrade if I set the phone_number to be the index? Considering that all phone_numbers are unique in this table. If the phone_number is the index, does this mean that mysql will know how to go directly to the row to update instead of reading many rows and find the right row ? Is that the purpose of an index or multiple indexes ?

Edit: I just changed the "UPDATE" query to find the row by phone_id (which was primary key and unique), it was a huge difference. Makes sense for me now, it no longer has to look in each row in order to find the phone_number, it can find it faster by phone_id:
You speak of "the index" so I assume you mean "the clustered index."  I'd actually start by just slapping a unique index on phone_number - if you're confident that it really is and always will be unique, and if it's the field you most often filter by.

If it is unique, it's a good example of a "candidate key" - you could, technically, use it as a primary key.  However, it's also a "business key" - driven by human logic, and therefore susceptible to change, unlike an IDENTITY or other machine-generated sequence, like your phone_id field.  Biz keys are generally poor candidates for the PK, thus sticking with your current PK/clustered key.