共計 1278 個字符,預(yù)計需要花費 4 分鐘才能閱讀完成。
今天就跟大家聊聊有關(guān) Java + Mybatis 如何實現(xiàn)電商系統(tǒng)分表查詢,可能很多人都不太了解,為了讓大家更加了解,丸趣 TV 小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
在開始之前,我先啰嗦一點理論知識。說實話,我們每個系統(tǒng)并不是一上來就開始分表,分庫。而是在數(shù)據(jù)量達到一定程度,且各種優(yōu)化手段都使用過后,仍然存在系統(tǒng)瓶頸的時候,才使用分表。因為分表會加大業(yè)務(wù)的復(fù)雜程度,通常都是不得已而為之的操作。
一般的,MySQL 在單表達到千萬數(shù)據(jù)量同時還在持續(xù)增長的時候,就需要想辦法優(yōu)化設(shè)計和實現(xiàn)了。通常我們的優(yōu)化手段有下面 6 個步驟:
第一優(yōu)化你的 SQL 和索引,這種效果立竿見影。采用這種優(yōu)化方式后,若還存在性能瓶頸,可以采用第二種架構(gòu)設(shè)計。
第二加緩存,memcached、redis 等。針對熱點數(shù)據(jù)做優(yōu)化,緩存是現(xiàn)在系統(tǒng)必須的且可靠的一種手段。
第三以上都做了后,還是慢,就做主從復(fù)制或主主復(fù)制,讀寫分離,可以在應(yīng)用層做,效率高,也可以采用第三方工具。
第四如果以上都做了還是慢,不要想著去做切分,mysql 自帶分區(qū)表,先試試這個,對你的應(yīng)用是透明的,無需更改代碼。但是 sql 語句是需要針對分區(qū)表做優(yōu)化的,sql 條件中要帶上分區(qū)條件的列,從而使查詢定位到少量的分區(qū)上,否則就會掃描全部分區(qū),另外分區(qū)表還有一些坑。這一條對數(shù)據(jù)庫的知識要求比較高,如果公司沒有配備 DBA,或者技術(shù)儲備不足的情況下,要慎用。
第五如果以上都做了,那就先做垂直拆分,其實就是根據(jù)你模塊的耦合度,將一個大的系統(tǒng)分為多個小的系統(tǒng),也就是分布式系統(tǒng)。這是現(xiàn)在各大系統(tǒng)熱衷采用的方案,可以優(yōu)先考慮。
第六才是水平切分,針對數(shù)據(jù)量大的表,這一步最麻煩,最能考驗技術(shù)水平,要選擇一個合理的 sharding key。為了有好的查詢效率,表結(jié)構(gòu)也要改動,做一定的冗余,應(yīng)用也要改,sql 中盡量帶 sharding key,將數(shù)據(jù)定位到限定的表上去查,而不是掃描全部的表。
針對 mysql 數(shù)據(jù)庫一般都是按照這個步驟去演化的,成本也是由低到高。好了,現(xiàn)在介紹完這些知識后,我就來給大家一個簡單的分表實現(xiàn)。
假設(shè)我們現(xiàn)在有 1000 萬數(shù)據(jù),項目要求需要分 2 個表。比如,xttblog 表會被分成 xttblog_0 和 xttblog_1。注意,我這里只是舉例,實際業(yè)務(wù)中,會根據(jù)具體的數(shù)據(jù)量,和增長趨勢進行水平分表,分表數(shù)量也將遠遠的超過幾十個。
根據(jù)上面的說明,我需要對 1000 萬條數(shù)據(jù)分成兩個表,那我的做法就是,將利用 xttblog 表的自動增長 ID 來實現(xiàn)分表。id%2 == 0 的操作表 xttblog_0,同理 Id%2 == 1 的操作表 xttblog_1。
你理解了這個之后,再來看看我們 MyBatis 對分表查詢的相關(guān)代碼吧。
這個 SQL 雖然很簡單,但分表會影響到其他一些業(yè)務(wù)的復(fù)雜度。
現(xiàn)在,假設(shè)我們要查詢 1000001 的數(shù)據(jù),那么我們的實際執(zhí)行的 SQL 就如下面所示:
看完上述內(nèi)容,你們對 Java + Mybatis 如何實現(xiàn)電商系統(tǒng)分表查詢有進一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注丸趣 TV 行業(yè)資訊頻道,感謝大家的支持。