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

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

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

mysql中，分表查詢和索引查詢哪個更快？

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

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

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

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

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

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

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

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

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

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