mysql支撑千万级的数据是否会有问题？

如果不考虑备份恢复之类的维护，支持3000w应该是可以的。可惜啊，mysql下边的海量数据备份恢复可没有Oracle、DB2等那样强有力的支持啊。

     哈哈,现在要是有人告诉我, 用磁带机做实时的数据存储, 我真会晕倒了! 拜托, 磁带机都是用来做备份的. 谁都知道磁带的读操作都是顺序操作, 要用来做实时的随机查询, 你觉得会有效率么?

世界上还有一种机械手是用来换带的机器。。。。。
不好不代表没有人用。。。。。。

数据库重构和代码重构一样重要，
从设计的角度解决问题比让Mysql去承受压力来的好

经典，绝对经典。

关于mixi，转一篇。

mixi.jp：使用开源软件搭建的可扩展SNS网站

于敦德 2006-6-27

Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。

下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。

首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。

这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。

图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。


兼回答上面一位同学的问题“为什么血JAVA的同学不喜欢分表？”

因为在血JAVA的同学看来，hibernate等工具对于切表没有良好的支持，什么东西都要自己写大量的SQL，这简直是不可思议的重复劳动，所以，不喜之。其实这个玩意也能实现，hack一下hibernate的SQL生成代码，或者，也可以等ajoo的JRC。

哦,我刚刚参加工作的公司,使用的是Oracle734版本,客户是全国零售业前十的一家集团企业,02年春节的初一/初二/初三晚上.每天晚上仅仅一个流水表的增量就超过了1kw,也可能是库表设计存在问题导致数据量过大...但是oracle是很强劲的.千万级数据对于IBM小型机下面的oracle来说根本不伤筋骨,为了BI系统还做过海量测试,只有当数据量达到10亿的时候,Oracle8和DB2 7才会出现了垂直差距.不过这些都是4年前的数据

最后,mysql对千万级的数据也是没有问题的.你可以分库或者做Master/Slave....当然需要有一个好的DBA