How to find and/or fix missing indices?
Disclaimer, as with other answers, this is aimed at a fairly technical person who kinda understands what they're doing and has made lots of backups :-)

As Sophie points out you can find the exact problem looking at the latest log in the ConfigAndLog directory.

For several of us the problem has been that there's a key defined incorrectly and the script's current response is to try a CREATE INDEX... statement, but it already exists, so it fails. Furthermore dropping this index with a simple DROP KEY &lt;keyname&gt; ON &lt;table&gt; .... cannot be done where a foreign key (FK) depends on having an index on those columns, as pointed out by Aidan

Temporarily disabling FKs can be problematic. The way I got it up and running was as follows:


Run the fixer, either from the status page or (for drupal users) with  

drush cvapi System.updateindexes


If it didn't work, read on.
Inspect the latest file in ConfigAndLog to find the table where it died. In my case this looked like  

CREATE UNIQUE INDEX UI_case_contact_id ON civicrm_case_contact
(case_id, contact_id) [nativecode=1061 ** Duplicate key name
'UI_case_contact_id'


So it's the UI_case_contact_id key that's the problem here.
Attempt to delete that key, if this works you can go back to step 1.

drush civicrm-sql-cli
MariaDB [your_db]&gt; DROP INDEX UI_case_contact_id ON civicrm_case_contact;

If deleting the key fails due to a FK constraint, e.g. like this:  

ERROR 1553 (HY000): Cannot drop index 'UI_case_contact_id': needed
in a foreign key constraint.


Then create the same key with a different name - copy the definition from the error message in (2), e.g.

CREATE UNIQUE INDEX my_temp_key ON civicrm_case_contact
(case_id, contact_id);


You should now be able to go back to step 3 and successfully delete the original key since now the FK can depend on your new key called my_temp_key.
Re-run the updater, hopefully it's ok  (on that table/key at least) now. If so you can then delete your my_temp_key with

DROP INDEX my_temp_key ON civicrm_case_contact;


Nb. Several of us have had this part fail. This means the update script has not created the index for some reason. If this happens I'd advise it would probably be best practise to reissue the original CREATE INDEX command from the log (step 2 above), then you should be able to drop your temporary key ok. This way you leave the schema exactly as CiviCRM expects it to be, which is definitely going to be helpful in the long term.


I put this solution together standing on the observations shared by others credited above, just thought it might be useful for me to spell out a step by step process. :-)