Are multiple indexes on MYSQL table reason for slow UPDATES and INSERTS?

To answer the specific question:

• No, an extra index on (entry_date) or two would not hurt performance of updating a different, title column.

Additionally:

• No, the version of MySQL, 5.6, is not too ancient, even if some modern features (like window functions) are missing. You should have decent performance with decent hardware.

We can only speculate on the issue in hand but what could be wrong or explain it:

• old, inefficient hardware: check the disk specifications, measure it's preformance.

• fragmented index/table. Check MySQL docs and old questions/answers here of how to defragment MyISAM tables (OPTIMIZE TABLE).

Last but not least:

• Your table is using MyISAM engine, which is old news. InnODB has replaced it as the default engine in MySQL years ago. There is no active development of this engine. It lacks several features compared to InnoDB (transactions, foreign key constraints, etc) and performance in most work loads. I strongly suggest you change your table (after testing of course that your apps and procedures do not break) to use InnoDB.

• Importantly to your Question, InnoDB can perform SELECT and UPDATE at the same time (usually). MyISAM completely locks the table; the update or select must finish before the select or update can even start.

• When switching from MyISAM to InnoDB, be sure to adjust key_buffer_size and innodb_buffer_pool_size.

Indexes do slightly affect performance of INSERT and DELETE operations but generally this is negligible especially if your indexes are well planned and you don't go overboard by putting 30 indexes on the same table each with 30 different combinations of fields. (Generally I stick to a 5 by 5 guideline - 5 indexes max, 5 fields per index max. Of course this is just a guideline and not a hard rule).

That being said, indexes actually are used to increase performance of UPDATE and SELECT queries because the index is used to locate the rows to either UPDATE or SELECT.

The drastic change you're seeing is doubtful to be related to entry_date index you discovered (do you know if that was recently added or has been there already prior to the performance change?).

Two things you should look into is:

1. If the previous indexes for your queries are still being used, especially for UPDATE and SELECT queries (and if they are being seeked on or is a scan operation occuring now). This can change due to changes in table statistics of the data over time. You can use the ANALYZE statement to check the statistics of a table.

2. The other thing you can look into is index fragmentation, which is a natural occurrence over time. This happens as more data is added to a table. (Generally this shouldn't be a concern on a small table like yours, but it's worth checking into it anyway.)

I'll continue to update my answer with more things to look into as I think of them. Running an EXPLAIN on your queries may help clue you in on the issue too. Is try to separate the UPDATE and INSERT statement that are running slowly and try to understand if they are being affected by the same root cause (since again they act somewhat inversely to indexes, INSERT are negligibly slower but UPDATEs usually benefit from the correct index and should be faster.)