mysql分區(qū)表和分表哪個(gè)好？

謝謝邀請我。如果資產(chǎn)記錄表是基于常識的話，首先里面的數(shù)據(jù)不應(yīng)該定期清理。根據(jù)你目前的數(shù)據(jù)量，可以算出一個(gè)月1500萬-2000萬左右有一定增長率的數(shù)據(jù)量。

建議初期可以考慮月表或者哈希表。分區(qū)表臨時(shí)頂下的數(shù)據(jù)量突然增加，作為臨時(shí)方案是可以的。讓讓我們考慮制作一張長期穩(wěn)定的桌子。

mysql中，分表查詢和索引查詢哪個(gè)更快？

子表和索引不是一個(gè)可選擇的問題。通常使用MySQL時(shí)(其他數(shù)據(jù)庫也是如此)，大多數(shù)情況下必須增加索引。好處是查詢速度大大提高，數(shù)據(jù)越多越明顯。缺點(diǎn)是會(huì)在一定程度上影響添加、修改、刪除的速度，但這種影響相對于查詢效率的提升來說不值一提。

當(dāng)單個(gè)表的數(shù)據(jù)量進(jìn)一步增加，比如增加到幾千萬或者上億的級別，單個(gè)MySQL已經(jīng)不足以支撐這么多的數(shù)據(jù)了。這時(shí)候就要考慮分區(qū)、表或者數(shù)據(jù)庫了。當(dāng)然，分表后，每個(gè)子表中仍然可以有索引。

如果非要說分表查詢和索引查詢哪個(gè)更快，在數(shù)據(jù)量沒有達(dá)到分表的水平時(shí)，比如只有一百萬的數(shù)據(jù)量，我覺得索引查詢更快。畢竟分表查詢也需要程序路由到數(shù)據(jù)所在的分區(qū)，同樣需要時(shí)間。

告訴我更多關(guān)于表拆分的信息。當(dāng)MySQL單表數(shù)據(jù)量小于1000萬時(shí)，性能更好。超過1000萬，性能就會(huì)下降。超過5000萬或者6000萬的時(shí)候，性能下降會(huì)更明顯。這是要考慮表拆分的。

表拆分的另一個(gè)好處是單臺服務(wù)器的性能畢竟有限，比如磁盤的IO。表拆分后，子表部署在不同的磁盤上(或者直接分庫)，可以利用多臺服務(wù)器的資源，更好地支持高并發(fā)。

數(shù)據(jù)庫和表劃分的常用策略:范圍劃分:按照一個(gè)字段的區(qū)間進(jìn)行劃分。比如按照id，一個(gè)分區(qū)從1到10萬，一個(gè)分區(qū)從10萬到20萬。

哈希分區(qū):定義一個(gè)表達(dá)式，并對表達(dá)式的結(jié)果進(jìn)行分區(qū)。例如，如果id是整數(shù)的模，則結(jié)果是1的分區(qū)，結(jié)果是2的分區(qū)。

業(yè)務(wù)領(lǐng)域劃分:這個(gè)很好理解。在業(yè)務(wù)數(shù)據(jù)中選擇一個(gè)適當(dāng)?shù)淖侄巫鳛榉謪^(qū)字段。比如按照公司代碼，公司代碼1(北京)是分區(qū)，公司代碼2(天津)是分區(qū)；當(dāng)然，公司名稱北京/天津等字段一般不選；但是，這種分表策略不能保證平均數(shù)據(jù)。比如北京有5000萬數(shù)據(jù)，天津有500萬數(shù)據(jù)。

雖然表/數(shù)據(jù)庫拆分看起來很美，但是也存在很多問題:跨數(shù)據(jù)庫關(guān)聯(lián)、分布式事務(wù)、結(jié)果集合并/排序等等，這些都是需要考慮和解決的。

我會(huì)繼續(xù)分享Java開發(fā)，架構(gòu)設(shè)計(jì)，程序員職業(yè)發(fā)展等等。希望得到大家的關(guān)注。