海量数据就不要考虑mysql了
曾经有公司用mysql开发电信系统
结果
后来第二版赶快换成Oracle

解决方案 »

  1.   

    曾经有公司用mysql开发电信系统
    ==============
    哈哈,活该。
      

  2.   

    现在公司用的是mysql数据库开发产品,现在这个版本不考虑更换数据库,以后可能会换。在不更换数据库的前提下,有什么好办法吗?
      

  3.   

    上亿条记录,这个,有点为难Mysql了吧
    最差,换个PostgreSQL吧~~~
      

  4.   

    领导让用mysql,现在还不能改数据库,很晕头已经大了不止一圈了
      

  5.   

    我曾经考虑过将这些数据按照id分成若干个表存储,然后做一个mapping表来映射,每张表存一定范围的id,查询的时候先到mapping表查到所要记录在哪张表里,再去相应表里查询。后来发现5.1支持分区表了,就应该不用手工去做这样的工作了,但是如果数据都存放在一张表里,还是怕有问题啊
      

  6.   

    使用mysql 不管你多牛哪怕你是mysql的开发人员,你会碰见各种各样的其他的好数据库不存在的问题。
      

  7.   

    to soapbubblebubble(肥皂泡):看见你上面得分析,其实分析是正确地,可以采用数据库散列来做。单台Mysql跑到500W条数据就很不容易了,但是如果多台服务器来做,每台分到若干条记录,做个集群式地数据库,应该是能够满足你地要求地。from: http://blog.csdn.net/heiyeshuwu/archive/2006/04/29/697498.aspx【数据库集群和库表散列】大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
      

  8.   

    我觉得MySQL能支持,关键问题是,这些上一亿条数据是什么关系,处理的好,MySQL绝对可行!
    MySQL最初就是为了零售商设计的,就是要存储大量的数据!