一次資料庫優化的對話

2022-03-13 20:45:24 字數 1264 閱讀 9072

那天夜裡的時候,我去十三哥屋裡找他,他正在敲**。平時我找他, 都是談技術,畢竟都是程式設計師,除了這一點,其它的共同愛好,我們也沒有。

不過這一次,不是談技術。房子要到期了,我是要問他,是繼續合租,還是各尋它途。 他說要去北方,他女朋友在北方。這點我理解,我要去東南,我女朋友在東南。

租房的事情談過後,他向我揚揚眉,有個好東西,說要告訴我。 我知道,他在炫耀,他想裝逼,他有準備。 我想用嘲笑,壓制他的炫耀,但我沒有,而是故做平靜的說:說說看。

他說他們公司,遇到乙個問題,乙個 mongodb 的資料庫,查詢時間太長。 我點點頭,表示讓他繼續。他說之前還好,資料量比較少,這段時間業務很好, 資料開始增多,查詢經常超時。我皺下眉,表示一下困惑。他繼續說, 索引也加了,能優化的都優化了,仍然超時。我看著他,沒有表情,等著他繼續。 他停頓了一下,然後問我,你覺得怎麼辦?我說我想想。

我不說話,看著屋頂。他笑著看著我,看著我苦苦的思索,等待著我的答案。 我低下頭,沒有說答案,而是問向他,他們是怎麼解決的。

他說那天下午,他們老大找到他,講了相同的事情,問了相同的問題,他也沒有回答。 他的老大笑笑,說可以"分表"啊。之前的表裡面,放著所有的記錄,資料快到六百萬時, 出現了查詢超時,如果按照業務劃分,可以分成十幾個表,每個業務的資料,只放到自己的表裡, 每個表的資料,都會降低很多。 他們建了新錶,舊表保持原樣,只在舊表增加,不再進行查詢,查詢操作,都轉移到了新錶。 新錶的字段,也由舊表的九個,變為現在的四個,這四個是必須的,多餘的全部去除。 他們分表過後,效果確實很好,每次都不超時。

他看著我,表情透著滿足,那是學到新知識後的表情。

我繼續問他,他們的業務有多少,他說十八個。我說那就是十八個表,他說是的。 我又問他,資料最多的業務,佔總資料的多少,他說大概一半。 我繼續問,如果說,我說如果,你們公司很牛逼,所有業務都增長加倍, 目前最好的業務,以後的資料量,可能和現在的總資料量一樣,那時候該怎麼辦?

他皺皺眉,說確實也是個問題。

我問他,查詢時的條件,是什麼資料型別,他說三十六位的字串,類似 md5。 我說可以對這個欄位做 hash ,雜湊到多個表,比如 128 個表,如果 hash 函式選的比較好, 結果比較隨機,那麼每個表的資料,也會比較隨機,表裡的資料就會比較平均, 這樣就能讓表裡的資料,降低兩個數量級。而且業務改變了,也不影響表的結構。

他說看起來,這樣倒也行。

他問我,這方法,是從**看到的,我說自己想到的。他說別吹牛逼,快點告訴我。 我說我也忘了,這是我自己想到的,還是從**看到的。不過現在,這知識已經和我融為一體,那就是我的了。

十三哥戲謔的看著我,說:你又開始裝逼了......

同步發表:

記一次資料庫的實戰

話不多說 直接開始 開始我們的敲 的工程吧 首先匯入標頭檔案 import tkinter import tkinter.messagebox import pandas as pd import numpy as np import matplotlib.pyplot as plt from sk...

記一次資料庫事務鎖

最近在做專案的時候碰到乙個問題,事務鎖。transactionoptions tos new transactionoptions tos.isolationlevel isolationlevel.repeatableread 行鎖 只會鎖住當前操作的那一行資料,當前表的其他資料不受影響。已驗證 ...

記一次資料庫踩下的坑

公司部署了一套系統,之前在別的地方部署沒有問題,執行正常,但是在濟南部署時就出現了問題 出現的問題是 錯誤日誌資訊不能插入錯誤資訊的日誌表中,導致前台查不到錯誤資訊資料 1 首先檢視錯誤日誌查詢的sql,確實沒有資料產生,這就排除了是前台不載入的問題 2 之後排查節點狀態記錄表,發現錯誤記錄的標誌產...