如果只有几亿条数据，不需要分表处理。但是肯定不能写SELECT * XXX这样的语句，因为这是不明智的选择。数据检索，主要有两个方面的性能设计指标，第一个，就是检索特定范围内的数据，比如只需要特定的几列，就没必要检索所有的列。有特定时间段的，就没必要筛选所有时间范围内的数据。第二个，是避免数据库引擎做重复的工作。这个很多人都没有避免，用户A检索了一条数据，然后用户B检索了一条同样的数据，这是很低级的行为，因为这意味着数据库引擎做了一次无用功。正确的做法是设计缓存层，把涉及重复检索的数据，加载到内存中，以降低数据库引擎的压力。
成都网站建设哪家好，找创新互联！专注于网页设计、重庆网站建设公司、微信开发、成都小程序开发、集团成都企业网站建设等服务项目。核心团队均拥有互联网行业多年经验，服务众多知名企业客户；涵盖的客户类型包括：成都纸箱等众多领域，积累了大量丰富的经验，同时也获得了客户的一致赞誉！
mysql在常规配置下，一般只能承受2000万的数据量(同时读写，且表中有大文本字段，单台服务器)。现在超过1亿，并不断增加的情况下，建议如下处理：
1、分表。可以按时间，或按一定的规则拆分，做到查询某一条数据库，尽量在一个子表中即可。这是最有效的方法。
2、读写分离。尤其是写入，放在新表中，定期进行同步。如果其中记录不断有update，最好将写的数据放在 redis中，定期同步。
3、表的大文本字段分离出来，成为独立的新表。大文本字段，可以使用NOSQL数据库。
4、优化架构，或优化SQL查询，避免联表查询，尽量不要用count(*), in，递归等消耗性能的语句。
5、用内存缓存，或在前端读的时候，增加缓存数据库。重复读取时，直接从缓存中读取。
不进行结构优化的话只能用缓存了
讲结果缓存进 memcache ，并记录缓存 hits 和 时间，每次先检查是否在memcache 里，在的话直接返回
不在的话就去数据库查询，然后看memcache是否满了，不满就添加到memcache里。否则就不添加。
另外运行一个守护进程，对缓存时间过长并且hits 很低的记录删除掉，清除memcache空间。
看你的是什么数据：
关系型数据：可以参考ali和京东用mysql集群来解决
非关系型数据：使用nosql集群来解决，MongoDB，Redis等
当然数据量特别大，查询很频繁的要利用好缓存
sql server 到底能否处理百万级，千
最近又想起曾经被忽悠过n 次的问题。
刚毕业的时候，很多次去面试的时候被问及sql server 能处理能力，
以及上百万级别的数据的优化问题？我当然是说东又扯西的，说了一大堆方法
我吹你吹了半天后，得到的提问着告诉我的很轻描淡写的答案是：不行，
sql server 不行，百万级别还是换oracle 好。
我当时总是很茫然的接受答案。因为我没玩过，我没发言权。(但是我搞
的缘由？是到今日，自己面试别人了，也还是不明白当时那些面试官的心态。)
。。。。。。两年时间过去了。。。。。。
我很有幸在一个小门户（其实也还好，不是那么小了），玩过百万级的数
据了。真是很荣幸还能玩到bbs 库这样的实时操作比较多的库。
当我再一次在面试中被问到sql server 的处理能力的时候，我能很有底
气的告诉他们sql server 能承受百万级别的处理能力，我也实践证明了它能。
这时候面试官总是表现得思维很敏捷，问题又很快出来了，处理千万级别的数
做。 我再次追问面试官给出的答案当然还是无情的否认了sql server。
。。。。。又两年时间过去了。。。。。。
目前又有幸玩门户的bbs，记录是过亿的。每天这过亿记录的表的查询次
数过了千万，我当然现在没有去面试，但是我还是真心的在这里希望不要碰到
问我sql server 处理百亿级，千亿级的数据的性能问题，更不希望告诉我答案
是换oracle。
sql server 我真为它难过。在这里我要为sql server 平反也想在此也问问各
位，目前用sql server 处理数据的级别和对它的看法，当然也可以评论下其他
人对sql server 的看法。
单表一亿？还是全库1亿？
1.首先可以考虑业务层面优化，即垂直分表。
垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。
如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.
如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。
2.架构上的优化，即水平分表。
水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。
如按照id分表，末尾是0-9的数据分别插入到10个表里面。
可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。
实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。
最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。
cobar的逻辑层次图：
不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。
另外，之前关于水平分表的实现方式，也可以通过表分区来实现。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。
分区只需要一次本地数据迁移的操作。
而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。