我们的数据库还在设计阶段。我们预计数据量将会很大，一年的时间里，一张表，就会产生100亿条数据，表结构，如下id,userid,createddate,等等正常情况下，100亿条记录如果都存在一个表里，那么如果通过userid来查寻一定很慢。所以，请教各位在查询的性能优化上，表结构，数据库结构，有什么好的建议，用mysql实现，是否合适？提示，业务需求中的一个特性是：每个用户都有一个userid，用户只会查自己的数据，不会查看别人的数据。谢谢各位。

===========================================================================

所有的优化都包含两方面，技术的优化和需求的优化。单表100亿肯定不是一个好做法。即使每条只有1k，总的也差不多有10T，再考虑到备份，更复杂了。mysql单表也不支持10T数据。有一个办法，是根据日期创建新的表插入数据。另外在需求优化方面，可以是只查询近期的数据，那样速度最快。如果要查询历史数据，就单独做一个接口。

===========================================================================

我很好奇什么应用能在一年达到100亿的数据？还要用MySQL？简单的优化方法是分两个表存储，最近一段时间(如3个月)放在一个表里，其他放在历史表里，一般只查询第一个表。

===========================================================================

从硬件入手可以采取1、最简单的提升性能的方法就是提升硬件，增加硬件的投入效果立竿见影，不过这个主要是是投资方的可接受成本问题了。一般的来说从硬件方面的投资主要是购买大型机RS9000,购买磁盘柜(同时也是高可用的需要)，增大内存。这些都可以提升系统的速度。2、从软件方面来说首先应该尽量使用64位的数据库，同时数据库应当建立在裸设备上。3、对于亿级别的数据通常是历史数据，而百万以及千万级别的数据通常是交易数据，这两种确实有很大区别，历史数据多为了读取，交易数据通常是可修改的，在建立索引的时候要考虑插入的问题。4、通常有表分区功能的数据库就不需要在设计上进行分表设计，只有在数据库系统不提供该功能的时候才会采用分表设计。分区要建立在不同的磁盘上以提升IO性能。从软件架构和业务层面1.使用SNA进行缓存如：memcached和sina的memcachedb；2.ORMapping(如hibernate)的session缓存和线程级别缓存；3.使用“领域模型驱动”的分析设计方法分析业务；这里关键是"领域模型驱动设计"，因为性能之所以优化，而不是提升，是因为总有一天优化不下去；只有领域逐渐清晰才可能使系统具有伸缩性；

===========================================================================

100亿条记录如果都存在一个表里，这样的速度mysql肯定是要被摒弃，就算oracle也吃不消这样的数据量，你这一张表就吃掉N多dbf。建议把表结构分拆吧，比如说你查询可以做一个联合查询接口或视图，该视图可以通过多张users表演化而来，先前的user表被拆分成若干表，对常用用户的表单独处理，对不常用的用户会定时通过程序进行数据转移,当然oracle的索引是少不了的，不过从根本上看这么大的数据量的表设计就有问题，或许从整个项目的构架上去考虑，重新设计才能正确解决这张表的性能问题。

===========================================================================

楼上的回答都可以参考一下如果在mysql上只是提供查询功能，是否可以这样：建立总表，存放历史所有数据，再根据时间，比如2个月或者1个月一个表建立分表，如果只查询某个人的信息的话，查询分表就好了，要是进行统计的话，对总表进行操作，看情况增加缓存功能

===========================================================================

100亿数据量大了，mysql单表好支持不了都少。如果不拆分数据，只能用分区来存储了，查询的优化就不说了。

===========================================================================

分表吧...你看你的100y数据是否都需要查询或者调用..如果对查询不是很高...可以做bigfile放弃数据库存贮..靠文件流和偏移量读取..

===========================================================================

mysql不合适，数据太大了！考虑一下创建物理索引

===========================================================================

兄弟,你只有做分表了.你可分成10000张表,把数据拆分开,平均放到这些表中,这样每张表相当于100万条数据,我想应该很快的.分表的具体方法我们可以再讨论

===========================================================================

Mysql一张表有100亿才很快的话oracle早就关门了oracle有100亿也吃不消的你可以分到多张表里 比如按月来分

===========================================================================

只能分拆表