目前经常使用的关系型数据库如MySQL、SQL Server等，都是以“行”为单位进行存储，为了快速检索，也都采用了B树或其他索引技术。
从原理上来讲，表中的数据越多，索引树的范围越大，磁盘读取也越多，性能也就越低。
从实践角度来看，一般以百万到千万作为一个表的存储量级，超出该范围之后，性能就会下降，需要采用其他技术手段解决。
首先想到的就是能否将读和写分离，主数据库用于写入，读数据库（多个）用于对外提供查询，通过数据复制的方式将主数据库的数据同步到读库。该架构提升了数据库的读写能力，但对于主数据库的写入能力依然没法扩展。
其次，垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。如有多种业务类型，每种业务类型建立不同的表，tb1,tb2,tb3。如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月的记录。
再次，水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。如按照id分表，末尾是0-9的数据分别插入到10个表里面。
这样做的好处就是解决了数据存储容量的问题，但也带来了诸多弊端，不再一一阐述。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。分区只需要一次本地数据迁移的操作。而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面偶就不说了。
