最近碰到了个很有意思的问题，值得一写
给merge表和基础表添加索引时发生了一个问题，不管是先给merge表加索引还是基础表加索引，如果表数据量大都会导致加索引期间对merge表的查询不可用，因为使用merge表必须保证merge表和基础表的表结构一致。因此需要给merge表加索引时，必须坐好评估，确定merge表和基础表的数据量，先给基础表加索引，再给merge表加索引，在加索引期间使业务避免访问merge表即可，等merge表加完索引即可使用merge表查询。4000w条数据一个表加完索引大约4个小时
关于merge表和基表的一些坑需要注意
-
删除索引
问题:
若先删除了基表的索引，再去删除merge表的索引会有如下报错，因为此时merge表和基表的表结构已经不一致了，merge表完全不可用了。
解决方法:
1、删除merge表，重建
2、把基表的索引重新加回来，然后再删除merge表的索引
产生影响:
如果数据量大的话一旦你删除索引顺序搞错，会导致线上严重的故障。使用第一种方法肯定会把原表删除，删除重建期间业务无法查询merge表，这种方法比较推荐，因为drop表再建表时间相对短一点;第二种方法给基表加索引的时间视数据量而定，4000w条数据4个小时，要是merge表引用的基表有几十个的话，基表重加索引需要几天，显然不可取。
要点:
先删merge索引再删基表索引 -
添加索引
问题:
不管先给merge加索引还是先给基表加索引，在所有的表加索引期间都会导致对merge表的查询不可用
解决方法:
在加索引前对整个表进行评估，数据量大则通知开发加索引期间其他业务对merge表的查询不可用，让他们修改这方面的代码。等到基表和merge表的索引都添加完毕再恢复对merge表的查询。
mysql的文档写的更全
MERGE Table Problems
其中关于索引的一段
已经告诉你了必须保证基表和merge的表结构一致，因此添加索引导致不一致的解决方法也就很容易想到了，要么保持一致，要么删了重建