关于索引的疑问

[imiMi_]

先说下问题产生的背景：我有一个表t，其上有两个索引，我查询information_schema结果显示t表索引大小共47.09MB，然后我采用delete方式删除了大量t表数据，再去查询t表索引大小未产生变化。然后又尝试插入了大量数据，索引大小仍未变化。
再说下我的疑惑，对于上述问题，我的猜测是表采用的是InnoDb引擎，我的删除与插入操作仅仅被记录在了redolog当中，还未被真正的写入磁盘当中，磁盘上的索引还未被重构，所以查询出的索引大小未产生变化。
假设我猜测正确（本段的话是简历在我猜测正确的情况下），按照问题产生情况看，我删除、增加了数据，索引都未第一时间被更新，也就不存在增删改会导致索引重构影响增删改效率这个问题了，因为重构索引的过程那就应该是在数据库空闲时redolog写入磁盘过程中产生的，并不算作是影响了增删改的效率。那添加索引会导致增删改效率降低又作何解？
我思考的只有这么多了，如果我猜的不对，那为什么删除、增加操作都未立即对索引大小产生影响？何时会重构索引？

[AHUA1001]

你可以试试这个，虽然不是每次都好用，但是有些时候的确是好用的。
ANALYZE TABLE 表名;

[道不虚行只在人]

应该是，47m全放内存了，增加删除直接操作内存

[stelf]

重新分析表的统计信息

[遇星]

索引页也是一种数据页，索引的增删改跟表数据的增删改没有区别，都是把对应的索引页缓存到buffer pool，然后先改内存的索引页，写redo。 增就是插入新的索引行； 删只是先把索引行标记为已删除，并没有立刻清理并释放空间； 改对应的删+增，即先将原索引行标记为已删除，再插入一行更新后的索引行，标记为删除的索引行也不是立即就清理并释放空间的； 具体什么时候清理？MySQL后台有专门的线程隔一段时间就来处理这个事情，这个就不说太细了。 那么为什么索引会降低DML的效率，因为索引的维护虽然并没有立即刷新到磁盘，但是在内存里还是有相应的维护操作的，例如标记删除状态，以及插入新的索引行，以及索引页的分裂和合并等等。

[带我飞的云]

要看那两个索引还存在么？如果索引还存在的，分配给索引的空间还会为这个表保留的，如果索引被删除了，使用OPTIMIZE table t 后，索引的空间就会变为0