sql跨服務(wù)器多表查詢？創(chuàng)建鏈接服務(wù)器，然后跨服務(wù)器查詢相當(dāng)于跨數(shù)據(jù)庫(kù)查詢同一服務(wù)器。那么它 它只是幾個(gè)表的聯(lián)合查詢。mysql中，分表查詢和索引查詢哪個(gè)更快？子表和索引不是一個(gè)可選擇的問題。通常使用

sql跨服務(wù)器多表查詢？

創(chuàng)建鏈接服務(wù)器，然后跨服務(wù)器查詢相當(dāng)于跨數(shù)據(jù)庫(kù)查詢同一服務(wù)器。那么它 它只是幾個(gè)表的聯(lián)合查詢。

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

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

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

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

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

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

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

哈希分區(qū):定義一個(gè)表達(dá)式，并對(duì)表達(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萬(wàn)數(shù)據(jù)，天津有500萬(wàn)數(shù)據(jù)。

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

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