我們的數(shù)據(jù)庫還在設(shè)計(jì)階段。
我們預(yù)計(jì)數(shù)據(jù)量將會(huì)很大，
一年的時(shí)間里，一張表，就會(huì)產(chǎn)生100億條數(shù)據(jù)，
表結(jié)構(gòu)，如下
id,userid,createddate,等等
正常情況下，100億條記錄如果都存在一個(gè)表里，
那么如果通過userid來查尋一定很慢。
所以，請教各位
在查詢的性能優(yōu)化上，
表結(jié)構(gòu)，數(shù)據(jù)庫結(jié)構(gòu)，
有什么好的建議，
用mysql實(shí)現(xiàn)，是否合適？
提示，業(yè)務(wù)需求中的一個(gè)特性是：
每個(gè)用戶都有一個(gè)userid，
用戶只會(huì)查自己的數(shù)據(jù)，不會(huì)查看別人的數(shù)據(jù)。
謝謝各位。
===========================================================================
所有的優(yōu)化都包含兩方面，技術(shù)的優(yōu)化和需求的優(yōu)化。
單表100億肯定不是一個(gè)好做法。即使每條只有1k，總的也差不多有10T，再考慮到備份，更復(fù)雜了。mysql單表也不支持10T數(shù)據(jù)。
有一個(gè)辦法，是根據(jù)日期創(chuàng)建新的表插入數(shù)據(jù)。
另外在需求優(yōu)化方面，可以是只查詢近期的數(shù)據(jù)，那樣速度最快。如果要查詢歷史數(shù)據(jù)，就單獨(dú)做一個(gè)接口。
===========================================================================
我很好奇什么應(yīng)用能在一年達(dá)到100億的數(shù)據(jù)？還要用MySQL？
簡單的優(yōu)化方法是分兩個(gè)表存儲(chǔ)，最近一段時(shí)間（如3個(gè)月）放在一個(gè)表里，其他放在歷史表里，一般只查詢第一個(gè)表。
===========================================================================
從硬件入手可以采取
1、最簡單的提升性能的方法就是提升硬件，增加硬件的投入效果立竿見影，不過這個(gè)主要是是投資方的可接受成本問題了。一般的來說從硬件方面的投資主要是購買大型機(jī)RS9000,購買磁盤柜（同時(shí)也是高可用的需要），增大內(nèi)存。這些都可以提升系統(tǒng)的速度。
2、從軟件方面來說首先應(yīng)該盡量使用64位的數(shù)據(jù)庫，同時(shí)數(shù)據(jù)庫應(yīng)當(dāng)建立在裸設(shè)備上。
3、對(duì)于億級(jí)別的數(shù)據(jù)通常是歷史數(shù)據(jù)，而百萬以及千萬級(jí)別的數(shù)據(jù)通常是交易數(shù)據(jù)，這兩種確實(shí)有很大區(qū)別，歷史數(shù)據(jù)多為了讀取，交易數(shù)據(jù)通常是可修改的，在建立索引的時(shí)候要考慮插入的問題。
4、通常有表分區(qū)功能的數(shù)據(jù)庫就不需要在設(shè)計(jì)上進(jìn)行分表設(shè)計(jì)，只有在數(shù)據(jù)庫系統(tǒng)不提供該功能的時(shí)候才會(huì)采用分表設(shè)計(jì)。分區(qū)要建立在不同的磁盤上以提升IO性能。
從軟件架構(gòu)和業(yè)務(wù)層面
1.使用SNA進(jìn)行緩存如：memcached 和sina 的memcachedb；
2.ORMapping（如hibernate）的session緩存和線程級(jí)別緩存；
3.使用“領(lǐng)域模型驅(qū)動(dòng)”的分析設(shè)計(jì)方法分析業(yè)務(wù)；
這里關(guān)鍵是"領(lǐng)域模型驅(qū)動(dòng)設(shè)計(jì)"，因?yàn)樾阅苤詢?yōu)化，而不是提升，是因?yàn)榭傆幸惶靸?yōu)化不下去；只有領(lǐng)域逐漸清晰才可能使系統(tǒng)具有伸縮性；
===========================================================================
100億條記錄如果都存在一個(gè)表里，這樣的速度mysql肯定是要被摒棄，就算oracle也吃不消這樣的數(shù)據(jù)量，你這一張表就吃掉N多dbf。建議把表結(jié)構(gòu)分拆吧，比如說你查詢可以做一個(gè)聯(lián)合查詢接口或視圖，該視圖可以通過多張users表演化而來，先前的user表被拆分成若干表，對(duì)常用用戶的表單獨(dú)處理，對(duì)不常用的用戶會(huì)定時(shí)通過程序進(jìn)行數(shù)據(jù)轉(zhuǎn)移,當(dāng)然oracle的索引是少不了的，不過從根本上看這么大的數(shù)據(jù)量的表設(shè)計(jì)就有問題，或許從整個(gè)項(xiàng)目的構(gòu)架上去考慮，重新設(shè)計(jì)才能正確解決這張表的性能問題。
===========================================================================
樓上的回答都可以參考一下
如果在mysql上只是提供查詢功能，是否可以這樣：
建立總表，存放歷史所有數(shù)據(jù)，再根據(jù)時(shí)間，比如2個(gè)月或者1個(gè)月一個(gè)表建立分表，如果只查詢某個(gè)人的信息的話，查詢分表就好了，要是進(jìn)行統(tǒng)計(jì)的話，對(duì)總表進(jìn)行操作，看情況增加緩存功能
===========================================================================
100億數(shù)據(jù)量大了，mysql單表好支持不了都少。如果不拆分?jǐn)?shù)據(jù)，只能用分區(qū)來存儲(chǔ)了，查詢的優(yōu)化就不說了。
===========================================================================
分表吧...你看你的100y數(shù)據(jù)是否都需要查詢或者調(diào)用..如果對(duì)查詢不是很高...可以做bigfile放棄數(shù)據(jù)庫存貯..靠文件流和偏移量讀取..
===========================================================================
mysql不合適，數(shù)據(jù)太大了！考慮一下創(chuàng)建物理索引
===========================================================================
兄弟,你只有做分表了.你可分成10000張表,把數(shù)據(jù)拆分開,平均放到這些表中,這樣每張表相當(dāng)于100萬條數(shù)據(jù),我想應(yīng)該很快的.分表的具體方法我們可以再討論
===========================================================================
Mysql一張表有100億才很快的話 oracle早就關(guān)門了
oracle有100億也吃不消的
你可以分到多張表里 比如按月來分
===========================================================================
只能分拆表