计算机操作系统在这方面做了一些优化，当一次I/O时，不光把当前磁盘地址的数据读取到内存缓冲区内，而且把相邻的数据也都读取到内存缓冲区内。这样一来，在读取数据时产生的I/O就少了很多了。因为在数据库中，每一次I/O读取的数据我们称之为一页(page)，一般为4k或8k，也就是说，我们读取一页内的数据时，实际上才发生了一次I/O。
根据以上的描述，我们可以初步得出结论，增加索引前后的性能差距体现在磁盘读取过程。但是在添加新的索引之前，我是添加了一个唯一索引的，后来发现在mysql中，我添加的唯一索引被称为聚簇索引，而后面添加的索引称为辅助索引，因此，让我们再来看看聚簇索引和辅助索引的区别。
聚簇索引(clustered index)和辅助索引(secondary index) 聚簇索引(clustered index)每一个InnoDB存储引擎下的表都有一个特殊的索引用来保存每一行的数据，称为聚簇索引。通常情况下，聚簇索引是主键的同义词。在InnoDB中，mysql是这样选择聚簇索引的：
如果表中定义了PRIMARY KEY，那么InnoDB就会使用它作为聚簇索引；
否则，如果没有定义PRIMARY KEY，InnoDB会选择第一个有NOT NULL约束的唯一索引作为PRIMARY KEY，然后InnoDB会使用它作为聚簇索引；
如果表中没有定义PRIMARY KEY或者合适的唯一索引。InnoDB会在一个合成的列中自动生成一个包含行ID的隐含的聚簇索引。这些行使用InnoDB赋予这些表的ID进行排序。行ID是6个字节的字段，且作为新行单一地自增。因此，根据行ID排序的行数据在物理上是根据插入的顺序进行排序。
聚簇索引如何加速查询因为所有的行数据都跟聚簇索引存放在同一个地方，因此，通过聚簇索引访问数据行会更快。如果表十分大，跟使用不同地方保存数据和索引的存储组织来说，聚簇索引的结构会节省很多的I/O操作。（比如说，MyISAM使用了一个文件来保存数据以及另一个文件保存索引记录）。
辅助索引(secondary index)除了聚簇索引之外的所有索引都被称为辅助索引。在InnoDB里，辅助索引的每一行记录都包含每一行的主键列，辅助索引指向主键。InnoDB使用这个主键来查找在聚簇索引中的行。如果主键很长，辅助索引会使用更多的空间，因此辅助索引有利于存储引擎拥有长度更短的主键。
结论因此可以得出结论：
在第一次使用了唯一索引(u_id)的时候，InnoDB使用了唯一索引作为表的聚簇索引。而在InnoDB存储引擎中，count(*)函数是先从内存中读取表中的数据到内存缓冲区，然后扫描全表获得行记录数的。因此，使用唯一索引作为聚簇索引的时候，InnoDB需要先读取110W条的数据到数据缓冲区中，这里发生了很多次I/O，因此造成了主要的时间消耗。而添加了辅助索引后，mysql在执行查询时会使用内部的优化机制：即使用辅助索引来统计数量。辅助索引保存的是index的值，此时只需要读取一个字段，I/O减少了，性能就提高了。因此在InnoDB中，如果有统计整张表的数量的需求，可以考虑增加一个辅助索引。