大型電商項(xiàng)目數(shù)據(jù)庫設(shè)計(jì)時(shí)應(yīng)該注意的點(diǎn)

一、 id的設(shè)計(jì)

int（int）類型： 性能高 ， 但是分布式數(shù)據(jù)庫時(shí) ， id易重復(fù)

long（bigint）類型：性能高 ， 比int類型容納的數(shù)據(jù)更多 ， 但是還是會重復(fù)

String（varchar） ： 使用UUID ， 幾乎不會重復(fù) ， 但是性能略低

大型電商的數(shù)據(jù)庫是分布式的么？

究其原因 ， 數(shù)據(jù)庫分布式設(shè)計(jì)就是為了提高數(shù)據(jù)庫的性能 ， 能抗住更大的訪問量 ， 但是僅僅靠增加數(shù)據(jù)庫服務(wù)器臺數(shù) ， 來應(yīng)對高并發(fā)， 似乎成本過高， 而且效果并不顯著 ， 所以 ， 大型電商項(xiàng)目的數(shù)據(jù)庫一般采用中央集中式 ， 后再引入緩存數(shù)據(jù)庫 ， 此時(shí)大量重復(fù)的查詢操作交給緩存數(shù)據(jù)庫 ， 大大的減小了數(shù)據(jù)庫的壓力 ， 而且緩存存在于內(nèi)存中 ， 用戶獲得數(shù)據(jù)的時(shí)間也更短 。

二、 價(jià)格的設(shè)計(jì)

一般價(jià)格使用double表示 ， 但是double類型的數(shù)據(jù)對降低數(shù)據(jù)庫的執(zhí)行效率 ，而電商項(xiàng)目以性能最高為目的來設(shè)計(jì)整個(gè)架構(gòu) 。 所以價(jià)格采用int存儲

在前臺提交數(shù)據(jù)時(shí) ， 先乘100 ， 的到一個(gè)整數(shù) ， 進(jìn)行存儲 ， 在查詢時(shí) ， 前臺在通過js將介個(gè)除以100 ， 得到真實(shí)的價(jià)格 。 這兒樣就把數(shù)據(jù)庫的壓力分散到所有的客戶機(jī)中 。

三 、 圖片上傳存儲的設(shè)計(jì)

在前臺頁面將圖片進(jìn)行上傳 ， 然后將圖片保存在服務(wù)器本地 。

電商項(xiàng)目中以性能為核心， 肯定不能把圖片存在數(shù)據(jù)庫中（這樣會破壞索引）

把圖片上傳到服務(wù)器中后

判斷是否是圖片

判斷是否是病毒

重新生成唯一的名字

生成實(shí)際存儲路徑（需要考慮 ， 同一文件夾下同名文件的問題 ， 同一文件夾下問價(jià)過多導(dǎo)致目錄訪問時(shí)間過長 ， 或不能訪問的問題）

生成虛擬訪問路徑

創(chuàng)建實(shí)際路徑對應(yīng)的文件目錄 ， 并存儲

把虛擬訪問路徑存在數(shù)據(jù)庫中

然后把虛擬訪問路徑返回客戶端 ， 供圖片回顯使用 。

索引介紹：

索引存在的目的就是為了減少磁盤IO的次數(shù)

如 ： 生活中查字典 ， 會用到字典索引：

查“李”

找L

找Li

找李

還有一些 筆畫法， 偏旁法 ， ， 都懲治為索引 。

B-Tree無論數(shù)據(jù)量多大， 三次IO即可查出數(shù)據(jù)

索引的特點(diǎn)是有序的

所以 ， 像：圖片 、 商品描述這樣的大字段盡量不要存在數(shù)據(jù)庫中 ， 破壞數(shù)據(jù)庫索引之后 ， 查詢將從索引查找變?yōu)楸闅v查找 ， 非常慢

四、 盡量使用單表設(shè)計(jì)

在能使用單表設(shè)計(jì)的情況下盡量使用單表設(shè)計(jì) ， 避免外鍵關(guān)聯(lián)

外鍵關(guān)聯(lián)性能問題：

數(shù)據(jù)庫需要內(nèi)部維護(hù)外鍵關(guān)聯(lián)（本身是if語句） ， 在主從不鎖表的情況下我們在代碼中維護(hù)他

在數(shù)據(jù)庫中設(shè)計(jì)到增 、 刪、 該 ，的操作都會觸發(fā)相關(guān)的操作去檢查外鍵 ， 從而不得不小號額外的資源 。

最主要的問題： 外鍵的存在很容易導(dǎo)致數(shù)據(jù)庫的死鎖 。

四、 商品描述的設(shè)計(jì)

商品描述屬于大字段 ， 而在數(shù)據(jù)庫中大字段的存在會破壞表的索引 ， 導(dǎo)致查詢操作十分的慢 ，所以要分表存儲

總結(jié)

以上是生活随笔為你收集整理的大数据互联网架构阶段 大型电商项目数据库设计时应该注意的点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。