I don't have a real way to reproduce this, but I recently noticed that in all of my Midgard databases, there are numerous duplicate indexes. For example, this is from a database that was created using 2.6 and has since been updated to 2.8. There was no manual interference, all I did was running datagard upgrade whenever I installed a new MidCOM or Midgard version (started at 1.8.2 and installed every release since then):
HOW INDEX FROM `article`;
+---------+------------+-----------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+---------+------------+-----------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
| article | 0 | PRIMARY | 1 | id | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | topic | 1 | topic | A | 7 | NULL | NULL | | BTREE | |
| article | 1 | article_sitegroup_idx | 1 | sitegroup | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | article_name_idx | 1 | name | A | 7 | 10 | NULL | | BTREE | |
| article | 1 | metadata_creator_idx | 1 | metadata_creator | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_created_idx | 1 | metadata_created | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | metadata_revisor_idx | 1 | metadata_revisor | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_revised_idx | 1 | metadata_revised | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | metadata_approved_idx | 1 | metadata_approved | A | 3 | NULL | NULL | | BTREE | |
| article | 1 | metadata_owner_idx | 1 | metadata_owner | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_schedule_start_idx | 1 | metadata_schedule_start | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_schedule_end_idx | 1 | metadata_schedule_end | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_hidden_idx | 1 | metadata_hidden | A | 1 | NULL | NULL | YES | BTREE | |
| article | 1 | metadata_nav_noentry_idx | 1 | metadata_nav_noentry | A | 1 | NULL | NULL | YES | BTREE | |
| article | 1 | metadata_published_idx | 1 | metadata_published | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | metadata_exported_idx | 1 | metadata_exported | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | metadata_deleted_idx | 1 | metadata_deleted | A | 1 | NULL | NULL | YES | BTREE | |
| article | 1 | metadata_score_idx | 1 | metadata_score | A | 1 | NULL | NULL | YES | BTREE | |
| article | 1 | guid_idx | 1 | guid | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | sitegroup_idx | 1 | sitegroup | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | article_up_idx | 1 | up | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | topic_idx | 1 | topic | A | 7 | NULL | NULL | | BTREE | |
| article | 1 | sitegroup | 1 | sitegroup | A | 1 | NULL | NULL | | BTREE | |
| article | 1 | guid | 1 | guid | A | 15 | NULL | NULL | | BTREE | |
| article | 1 | topic_2 | 1 | topic | A | 7 | NULL | NULL | | BTREE | |
| article | 1 | up | 1 | up | A | 1 | NULL | NULL | | BTREE | |
+---------+------------+-----------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+
26 rows in set (0.00 sec)
I.e. there are two indexes for up and guid, and three indexes for sitegroup and topic.
In this admittedly extremely small table, the acutal data consumes 4,5K, the indexes 33,8K.
