返回信息流原文链接：http://hi.baidu.com/liuwaiiting/item/bdc31ed539646a3e48e1dda3
在中国互联网技术圈流传着这么一个说法：mysql单表数据量大于2000w条，性能会明显下降。所以这设计大数据存储时，多会以此为标准，进行分表操作。
首先：这个传说是错的，但是这个结论在产生时有重要意义。
传说起源：百度，当年DBA测试Mysql性能时发现，当单表的量在2000w量级的时候，sql操作的性能急剧下降。所以得到该结论。后百度的工程师流动到业界的其它公司，也带去了这个信息，所以就在业界流传开这么一个说法。
真相：Mysql为了提高性能，会将表的索引装载到内存中，实现高效操作。当年百度的数据库服务器的内存有限，当单表数据库到达2000w的量级时，内存放不下表的索引了，而需要把部分索引装载到磁盘中，此时出现了性能的明显下降。
正确的说法是：当一个表的索引无法放入到内存中会导致性能下降，而与实际记录的条数无关。
但是鉴于当时机器的限制，2000w的传说是有时代意义的错误结论。
这是一条镜像帖。来源：北邮人论坛 / database / #7226同步于 2012/11/28
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Database机器人发帖
关于mysql单表数据量大于2000w条的传说
liuwaiting
2012/11/28镜像同步10 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
如果只把mysql当做key-value来用，确实上亿没有问题
但是就正常的sql用途来说，2000w量级确实应该分表。文章在评论传说的时候去掉了传说的前提和背景，只评论它的结论，以此得出传说是错的，这个。。。
没看到这个前提？ “但是鉴于当时机器的限制，2000w的传说是有时代意义的错误结论。”
【 在 binux 的大作中提到: 】
: 如果只把mysql当做key-value来用，确实上亿没有问题
: 但是就正常的sql用途来说，2000w量级确实应该分表。文章在评论传说的时候去掉了传说的前提和背景，只评论它的结论，以此得出传说是错的，这个。。。
鉴于现在的机器限制，2000w依旧有意义
【 在 liuwaiting 的大作中提到: 】
: 没看到这个前提？ “但是鉴于当时机器的限制，2000w的传说是有时代意义的错误结论。”
无论数据库服务器现在用普遍48G、64G内存的机器。
还是4G、8G的机器。
采用2000w条为分表依据都是不对的。
而是应该根据实际表索引的测试结果，得到多少数量级的数据的索引是内存的极限。
并以此作为分表的依据。
【 在 binux 的大作中提到: 】
: 鉴于现在的机器限制，2000w依旧有意义
哪有那么闲。。。
【 在 liuwaiting 的大作中提到: 】
: 无论数据库服务器现在用普遍48G、64G内存的机器。
: 还是4G、8G的机器。
: 采用2000w条为分表依据都是不对的。
: ...................
唉，我都猜到你会这么回复了。
反正我的意思就是以2000W条作为什么mysql使用经验之谈、DBA军规什么的，都是没有依据的。
在一个大公司，这么分表不会出错，因为那里设备通常很好。
到了一个创业公司，设备可能降了几个档次，1000w可能内存都放不下了，还按照2000w分，就是瞎整。
【 在 binux 的大作中提到: 】
: 哪有那么闲。。。
1000w和2000w是一个量级的好吧。。
而且分表都是在设计的时候就想好了，都是按照最大可能数据量参考量级的，如果最大1000w还真不一定需要分表
【 在 liuwaiting 的大作中提到: 】
: 唉，我都猜到你会这么回复了。
: 反正我的意思就是以2000W条作为什么mysql使用经验之谈、DBA军规什么的，都是没有依据的。
: 在一个大公司，这么分表不会出错，因为那里设备通常很好。
: ...................
不是数据量级的问题好么...是索引规模的问题，每张表都不一样的.
【 在 binux 的大作中提到: 】
: 1000w和2000w是一个量级的好吧。。
: 而且分表都是在设计的时候就想好了，都是按照最大可能数据量参考量级的，如果最大1000w还真不一定需要分表
就是因为索引这东西算不出来才用数据行数来分析的啊
【 在 liuwaiting 的大作中提到: 】
: 不是数据量级的问题好么...是索引规模的问题，每张表都不一样的.
: