分表和索引并不是二选一的问题
通常使用MySQL时（其余的数据库也一样），大多数时候索引是必须要增加的，好处是查询速度提升非常大，数据量越多越明显；缺点是会对新增、修改、删除的速度造成一定程度的影响，不过这个影响和查询效率的提升相比，不值一提。
当单表中的数据量进一步增多，例如到了大几千万、几亿这个级别，单台MySQL已经不足以支撑这么多的数据了，这时候就要考虑分区、分表或分库了；当然分表之后，每一个子表中仍然可以有索引。
如果非要说分表查询和索引查询哪个快，当数据量没达到需要分表的程度时，比如只有一百万的数据量，我觉得还是索引查询快，毕竟分表查询还需要程序路由到数据所在的分区上，这个也是需要消耗时间的。
多说说分表的事儿
MySQL单表数据量在一千万以内的时候，性能是比较好的，超过千万性能会有下降，到了五六千万以上，性能下降就比较明显了，这是就要考虑分表了。
分表另外一个好处是，单个服务器的性能毕竟是有限的，例如磁盘的IO，分表后将子表部署在不同的磁盘上（也可以直接分库），可以利用多台服务器的资源，更好地支持高并发。
常见的分库分表策略
-
RANGE分区：根据某一个字段的区间，进行分区。比如按照id分区，1到10万一个分区，10万零1到20万一个分区。
-
HASH分区：定义一个表达式，对表达式的结果进行分区选择。例如把id和某个整数进行取模运算，结果为1的是一个分区，结果是2的一个分区。
-
业务字段分区：这个就容易理解了，在业务数据中选择一个合适的字段，作为分区字段。比如按照公司码分区，companyCode=1（北京）为一个分区，companyCode=2（天津）为一个分区；当然，一般不会选择companyName=北京/天津这样的字段；不过这种分表策略，不能保证数据平均，比如北京有五千万数据，天津有五百万数据。
分表/分库虽然看起来很美好，但是问题也不少：跨库关联、分布式事务、结果集合并/排序等问题，都是需要考虑解决的。