V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
darasion
V2EX  ›  MySQL

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

  •  
  •   darasion · 2012-04-17 23:31:32 +08:00 · 12933 次点击
    这是一个创建于 4587 天前的主题,其中的信息可能已经有所发展或是发生改变。
    27 条回复    1970-01-01 08:00:00 +08:00
    reus
        1
    reus  
       2012-04-17 23:34:12 +08:00
    分表,升硬件,调参数,换引擎,总能撑得住的
    ElmerZhang
        2
    ElmerZhang  
       2012-04-17 23:40:12 +08:00
    分表喽。。。
    whtsky
        3
    whtsky  
       2012-04-17 23:42:57 +08:00 via Android
    拆表...
    napoleonu
        4
    napoleonu  
       2012-04-17 23:49:59 +08:00
    没有这样的说法。
    mywaiting
        5
    mywaiting  
       2012-04-17 23:52:39 +08:00
    要是那样FB不是早就挂了啊!
    skydiver
        6
    skydiver  
       2012-04-17 23:59:14 +08:00
    @mywaiting fb必然用的不是mysql啊。。。
    summic
        7
    summic  
       2012-04-18 00:06:30 +08:00
    我们的一个单表就有2000万,有点慢,不一定非要分库分表,看业务,用partition也可以解决
    reus
        8
    reus  
       2012-04-18 00:08:26 +08:00
    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).

    也不会只用一种数据库系统的。
    mywaiting
        9
    mywaiting  
       2012-04-18 00:09:14 +08:00
    @skydiver |||-.- FB不是MySQL的大户么......歪楼了...........
    skydiver
        10
    skydiver  
       2012-04-18 00:21:42 +08:00
    @mywaiting 呃。一直印象里Facebook用的是Cassandra,搜索了一下原来也用MySQL
    virushuo
        11
    virushuo  
       2012-04-18 00:22:41 +08:00
    处理的好就没问题。抓虾当年以每天几百万的速度写入mysql,总量惊人。当然他们做了不少优化。
    darasion
        12
    darasion  
    OP
       2012-04-18 01:06:52 +08:00
    @virushuo 这些优化,一般来说,都有哪些措施呢?
    freefcw
        13
    freefcw  
       2012-04-18 03:19:33 +08:00
    @darasion 有什么问题做什么优化。。。没遇到问题不知道怎么优化
    Johnny
        14
    Johnny  
       2012-04-18 06:37:10 +08:00
    2000w 你要是不用复杂查询的话 小意思
    feiandxs
        15
    feiandxs  
       2012-04-18 08:00:20 +08:00
    既然楼主说的是听说,那说明楼主还没遇到2000万记录+严重性能问题。
    在从听说变成遇到的时间内,我觉得智慧的楼主完全能够解决这个问题~~
    你想想你见过的一些还在用早期版本的discuz论坛,轻松过2kw帖子,也挺欢快的。
    darasion
        16
    darasion  
    OP
       2012-04-18 08:17:57 +08:00
    @feiandxs 听说是不假;

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

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

    我就想求证下这种决策是否有必要。我知道我改变不了这个决策,也不想改变什么,只是纯好奇,想知道为啥要这样做。
    likuku
        17
    likuku  
       2012-04-18 09:16:45 +08:00 via iPhone
    用myisam似乎记得单表有超过1亿记录的。
    vitohe
        18
    vitohe  
       2012-04-18 09:19:52 +08:00
    @darasion 我觉得如果因为这种面向未来性能的考虑而给现在的开发带来障碍的话,是有点杞人忧天了。毕竟大多数项目都是渐进式增长的,不可能上线第一天就2kw条记录吧。
    正如@feiandxs 所说,在0~2kw的过程中,你会积累10w、100W、1000w各种级别的经验,等正真2kw的时候,我相信对你来说已经可能不是什么大问题了。
    likuku
        19
    likuku  
       2012-04-18 09:22:50 +08:00 via iPhone
    大内存(>64G)+SSD RAID5+多核多CPU,问题不大的
    muxi
        20
    muxi  
       2012-04-18 09:24:39 +08:00
    这个不能一概而论,2000w不知道楼主从何处得来,或者是多久以前别人得出的结论,现在软件都在发展,MYSQL 5.1和5.5的改进不是一点点,硬件也在改进,内存现在随便就能到32G,即使是5.1,2000w这个数字非常不靠谱,我经历的项目中,有不少单表超过8亿条的数据,适度优化后,增删改查速度也没有很多的下降,还能正常使用,唯一头痛的是当你改变表结构的时候会非常花时间,所以2000w这个数字更多的是出于表结构变更成本上的考虑。

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

    道听途说是不准的,分表是个好的方法,但首先是要改进你的数据库操作方式,不然即使分表了,依然会有很多问题,而且在某些情况下分表带来的维护工作量远远超过单表,最简单的例子就是当你的查询条件不包含你分表的条件的时候,查询就很痛苦。
    napoleonu
        21
    napoleonu  
       2012-04-18 09:27:58 +08:00
    过早优化是万恶之源,等问题来了再解决,身轻如燕。
    magic22cn
        22
    magic22cn  
       2012-04-18 09:36:33 +08:00
    table partition
    darasion
        23
    darasion  
    OP
       2012-06-13 22:13:32 +08:00
    更新一下,
    最后终于大家忍受不住它的不稳定,经过研究和pk,又开始计划换回普通的 mysql 了。
    ╮(╯_╰)╭

    而且据开发这个的人说,本来是用来做非常大的数据存储的,开发时并没有考虑功能强大,只是满足巨大的单个表的高并发增删查改需求;并不适合像我们那个项目使用。
    lyxint
        24
    lyxint  
       2012-06-13 22:46:10 +08:00
    我这里的mysql, 九千万条数据, 没有复杂查询,没有问题
    noahasm
        25
    noahasm  
       2012-06-13 23:53:13 +08:00
    单表1.4亿条记录,数据库目录168G,无压力。
    maddot
        26
    maddot  
       2012-06-14 00:07:42 +08:00
    以前我维护过一个日增50多万记录的表,总数过亿,分区加合适的索引后,没啥问题
    regmach
        27
    regmach  
       2012-06-20 06:34:27 +08:00
    搭车问4表(其中2个百万左右,2个百以内)同时读取,会不会很影响效率?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1012 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 21:30 · PVG 05:30 · LAX 13:30 · JFK 16:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.