中型网站，有不同分类的信息Info1, Info2, Info3, Info4, Info5, 这几类信息的数据结构大体相同，数据量大概是百万级的。
做法：
1. 将不同分类的信息作不同的表Table1, Table2, Table3, Table4, Table5
2. 将不同分类的信息加入到同一个表Table1请问：
哪种方案比较好？用2对于代码实现简单，会不会数据量太大导致查询效率低？MySQL一个表数据量有没有限制？谢谢！
做法：
1. 将不同分类的信息作不同的表Table1, Table2, Table3, Table4, Table5
2. 将不同分类的信息加入到同一个表Table1请问：
哪种方案比较好？用2对于代码实现简单，会不会数据量太大导致查询效率低？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、其它任何"关键数据"数据库。以上来自于自身实践和测试。个人观点，谨供参考。
否则SQL可能会有好多union all