听说 mysql 表超过 2000 万记录就会有严重性能问题，这是真的吗？该怎样处理？

分表，升硬件，调参数，换引擎，总能撑得住的

分表喽。。。

拆表...

没有这样的说法。

要是那样FB不是早就挂了啊！

@mywaiting fb必然用的不是mysql啊。。。

我们的一个单表就有2000万，有点慢，不一定非要分库分表，看业务，用partition也可以解决

http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
Facebook uses MySQL, but primarily as a key-value persistent storage, moving joins and logic onto the web servers since optimizations are easier to perform there (on the “other side” of the Memcached layer).

也不会只用一种数据库系统的。

@skydiver |||-.- FB不是MySQL的大户么......歪楼了...........

@mywaiting 呃。一直印象里Facebook用的是Cassandra，搜索了一下原来也用MySQL

处理的好就没问题。抓虾当年以每天几百万的速度写入mysql，总量惊人。当然他们做了不少优化。

@virushuo 这些优化，一般来说，都有哪些措施呢？

@darasion 有什么问题做什么优化。。。没遇到问题不知道怎么优化

2000w 你要是不用复杂查询的话 小意思

既然楼主说的是听说，那说明楼主还没遇到2000万记录+严重性能问题。
在从听说变成遇到的时间内，我觉得智慧的楼主完全能够解决这个问题~~
你想想你见过的一些还在用早期版本的discuz论坛，轻松过2kw帖子，也挺欢快的。

@feiandxs 听说是不假；

但是最近项目决策换用一种改进后的 mysql ，其中有一条原因就是标题中提到的这个2kw。

换用需要做很多的改动，很多的查询不支持，有很多限制，整个代码都要改动。

我就想求证下这种决策是否有必要。我知道我改变不了这个决策，也不想改变什么，只是纯好奇，想知道为啥要这样做。

用myisam似乎记得单表有超过1亿记录的。

@darasion 我觉得如果因为这种面向未来性能的考虑而给现在的开发带来障碍的话，是有点杞人忧天了。毕竟大多数项目都是渐进式增长的，不可能上线第一天就2kw条记录吧。
正如@feiandxs 所说，在0～2kw的过程中，你会积累10w、100W、1000w各种级别的经验，等正真2kw的时候，我相信对你来说已经可能不是什么大问题了。

大内存(>64G)+SSD RAID5+多核多CPU，问题不大的

这个不能一概而论，2000w不知道楼主从何处得来，或者是多久以前别人得出的结论，现在软件都在发展，MYSQL 5.1和5.5的改进不是一点点，硬件也在改进，内存现在随便就能到32G，即使是5.1，2000w这个数字非常不靠谱，我经历的项目中，有不少单表超过8亿条的数据，适度优化后，增删改查速度也没有很多的下降，还能正常使用，唯一头痛的是当你改变表结构的时候会非常花时间，所以2000w这个数字更多的是出于表结构变更成本上的考虑。

如果你的表结构不是经常变更，没有大量的join操作，2000w这个数字有点保守了，当然坏的数据操作方法其实用不了2000w就会产生大量的慢查询和程序异常。

道听途说是不准的，分表是个好的方法，但首先是要改进你的数据库操作方式，不然即使分表了，依然会有很多问题，而且在某些情况下分表带来的维护工作量远远超过单表，最简单的例子就是当你的查询条件不包含你分表的条件的时候，查询就很痛苦。

过早优化是万恶之源，等问题来了再解决，身轻如燕。

table partition

更新一下，
最后终于大家忍受不住它的不稳定，经过研究和pk，又开始计划换回普通的 mysql 了。
(_)

而且据开发这个的人说，本来是用来做非常大的数据存储的，开发时并没有考虑功能强大，只是满足巨大的单个表的高并发增删查改需求；并不适合像我们那个项目使用。

我这里的mysql, 九千万条数据， 没有复杂查询，没有问题

单表1.4亿条记录，数据库目录168G，无压力。

以前我维护过一个日增50多万记录的表，总数过亿，分区加合适的索引后，没啥问题

搭车问4表(其中2个百万左右,2个百以内)同时读取,会不会很影响效率?