mysql千万或者上亿的数据怎么设计数据库？

[findshine]

mysql百万或者一两千万的数据知道可以通过分表来解决，但是如果八九千万级别或者过亿级别的数据库应该怎么设计呢？

是不是会用到多个服务器？还望指教！

[牛尚小又何妨]

如果比较旧的数据很少被访问，通过合理设计索引和分表应该也可以吧

[zjcxc]

拆分到多个服务器是有必要的 当然，不能武断的说多大的量就一定要分表，多在的量一定要分服务器，这还是取决于具体的数据处理需求 但在设计上，如果你应对的是大数据，分表分服务器是必须要考虑的

[zjcxc]

分表通常可见的优势是我们可以把操作分散在多个表中 一方面是并行，比如统计1000万的数据，在一个表中统计依赖于数据库系统会不会并行，而在10个表中，就算数据库不支持并行，我们也可以自己并行处理10个表之后再汇总统计结果 另一方面是分散，比如我们对历史数据和当前数据，通常会有不同的处理需求，当前表数据变化频率，我们可能需要实时统计，需要比较多的索引，而历史表数据基本不变化，我们可能把统计结果写一张表，这样历史表可以不太需要索引 如果只考虑分表，不分服务器，那么对于海量的处理量而言，不但服务器要求足够好，还容易出问题（高负荷都在这一个点上），这个时候分服务器不但能够大大降低服务器的要求，还能够分化风险

[wandier]

这就要分多db啊，根据规则到不同的db上找数据，互联网成片上万台机器不都是这样管理的吗

[kampoo]

可以通过时间或者其他口径进行切片，原来有个项目中，有个大表是保存员工发送的消息记录，每年一亿条左右，5万员工，按年切片成表，每年的消息记录创建一个历史表，索引设计得当，查询速度满足要求，都保存在一台服务器上的一个mysql库运行多年。要不要分库或者分服务器，看需求包括业务需求和性能需求。

[偏安zzcoder]

分布式存储，优化SQL语句，合理创建索引，这几个算是比较常见的方法了吧

[LongRui888]

首先是分表，每个表的数据最好控制在百万级，是否要拆分服务器，这个看你的情况，如果负载很高，就得分库，然后把不同的库放到不同的服务器上了。