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

简单看了一下介绍，好像也是一个虚拟社区性质的网站。但是属于比较封闭的那种，不是随便可以加入的，只有受到邀请的人才能加入。

mixi.jp 是用的 mysql，但是按照应用和数据对数据进行了拆分。首先按照应用拆，例如邮件系统的和用户系统的数据库分离；然后按照数据特性拆，例如用户系统中按照用户名的首字母来拆。并不是一个表有那么多数据。

相对 mysql，我推荐使用 postgresql。目前我的一个应用（BBS类）单表已经超过1500万条记录。使用流畅，没有出现问题。为免广告嫌疑，域名就不提了。

我感觉楼上几位都说的很对，首先要对数据的用途和特性有充分的了解。然后就要靠扎实的数据库设计了。

   20-30亿条?呵呵,你一个表几个字段啊? 不会只是id 吧?  我假设你一条数据就100个字节(要真是商业系统, 一条数据哪只100个字节啊),你自己算算, 一个表至少需要多少表空间, 186G.
   你真还好意思说一个表....... 俺都有些无话可说了.

3000w条记录对与mySQL来说太大了。
且不说mySQL的单表文件有多少个G，从实际的角度也是非常冒险的事。

与商业数据库比较，靠单文件来做数据表表达的mySQL从基理上就非常脆弱，特别在大数据表、大并发写操作的时候。
尽管跟所有的数据库一样，lock机制用于mySQL单表同时写入出现故障的情况，但在大并发写入时，出现mySQL数据表或索引表损坏的几率还是不可忽略。这是我们多年的实践中发现的情况。

即便很少的字段、很少的索引，当数据量大到300w以上时，数据表的并发写入效率会猛然下降（非线性）。在不同的硬件环境中，300w这个阀值会有所不同，但都存在。

根据我们的测试，在大数据量、大并发写入时，运行于Solaris上mySQL的可靠性要高于运行于IA Linux上的。而运行于Windows上的性能和可靠性都最差。
根据我们的测试，在数据表记录高于1000w条，100并发写入时。mySQL on Linux的表损坏几率高于1/10w。比on Solaris和AIX高10倍左右。我猜想这个跟文件系统的可靠性有关。

我个人认为mySQL适用以下场合：
1、BBS——无论访问量多大，并发写入的负荷都很低。
2、内容发布系统——理由同上。但我更倾向于采用生成静态页面文件的方式来实现。
3、通讯录——当然用OpenLDAP也不错，但对于统计分析不太方便。
4、日志分析——做为中间临时表来使用。
5、小型的应用，如OA、MIS或Intranet中的一些非关键业务应用。

而以下应用可能并不适合采用mySQL。
1、零售系统数据库。
2、计费数据库。
3、ERP系统数据库。
4、财务（帐务）系统数据库。
5、实时写入（访问）的日志数据库。
6、其它任何"关键数据"数据库。

以上来自于自身实践和测试。个人观点，谨供参考。

数据库有836G,硬盘才300G,多余的536G怎么个存储啊?

如果有千万级别的数据，想必这项目利润也不小亚，何必冒险用mysql阿，这个是客户掏钱的，但万一系统崩了，就是你的责任了

用mysql支持千万用户的系统也不是没有，但我还不知道有只拿一个server来跑mysql的

没钱，从网上抓数据，就算一秒一条，一天就是60*60*24=86400，一个月就86400*30=2590000，一千万也用不了几个月呀

世界上有种存储器叫磁带机

都放表里？
数据挖掘之后
全都刻盘才是正道

MySql不是很熟，oracle肯定没问题了。做过一个性能改进的项目，性能测试数据中一个表里面有1亿多数据，HP-UX上的Oracle