鍍金池/ 問答/數(shù)據(jù)庫  網(wǎng)絡(luò)安全/ mysql分庫分表的疑問

mysql分庫分表的疑問

最近在研究分庫分的方案，沒什么經(jīng)驗(yàn)，有疑問向大家請教一下。
比如一個(gè)訂單表，有字段：下單人id，商品id，店鋪id，下單時(shí)間等

在做分表時(shí)，首先考慮按下單人id做分割，這樣買家查詢數(shù)據(jù)會(huì)更快，但是賣家一般按店鋪或者商品查詢訂單會(huì)不理想，還有客服、管理員等其他場景下的使用更會(huì)有這樣的問題。

但如果按商品id做分割，買家查詢會(huì)不理想。所以想向大家請教一下，應(yīng)該怎么處理？

回答
編輯回答
妖妖

分庫分表是解決查詢效率的問題。一點(diǎn)小想法，可不可以這么來理解
1.對查詢速度最敏感是用戶，優(yōu)先考慮以用戶ID來分割，優(yōu)化前端用戶的查詢速度
2.店鋪ID和訂單ID另建一張冗余表來建立關(guān)聯(lián)
3.訂單和商品是多對多關(guān)系，可以以商品ID來分表，并建冗余表關(guān)聯(lián)
4.可不可以引入其他技術(shù)來實(shí)現(xiàn)，比如mongodb、E Search

2018年3月1日 13:50
編輯回答
女流氓

我的想法：
1.下單人id就是user_id咯，user表肯定放到主庫里面的，而商品表似乎沒有想到對應(yīng)的shard_nodes那我也放到主庫中去。
2.我理解的店鋪應(yīng)該是和用戶關(guān)聯(lián)的，那就可以用user_id做shard_nodes將其存到分庫中區(qū)，然后用es做分詞.
3.下單既然是和用戶有關(guān)的行為,那同樣用user_id做shard_nodes將其存到放分庫中去

那么效果就來了，既然是分庫，那肯定不會(huì)存在單個(gè)shard庫中對應(yīng)表的數(shù)據(jù)量過于膨脹（比如下單表，如果全存到主庫中，假設(shè)下單積累量有100w那一次查詢就是100w的過濾操作,而如果根據(jù)user_id垂直分割，shard_routing到20個(gè)分庫中，那平均均攤的分庫也就5w下單數(shù)據(jù)量，這查詢肯定快很多）

綜上，去分庫獲取對應(yīng)user_id的用戶的下單數(shù)據(jù)，然后拿著其余字段去商品/店鋪等等取數(shù)據(jù)。
like 圖片描述

2018年6月8日 20:33