11 回答

TA貢獻2003條經驗 獲得超2個贊
這個需求僅僅是基于數(shù)據(jù)庫中現(xiàn)有的記錄來計算這幾個冗余字段并更新到會員卡表?不用管以后發(fā)生新的消費時同步更新這些冗余字段?
?
如果是這樣,那簡單啊。性能差也不是問題,找數(shù)據(jù)庫壓力小的時候,一批批慢慢跑嘛,總能跑完的。
?
其實更大的問題是,這些中途增加的冗余字段的數(shù)據(jù)初始化搞定以后,怎樣才能伴隨這新的消費發(fā)生而同步更新的問題。這才是要命的大問題。

TA貢獻1827條經驗 獲得超9個贊
會員卡700萬的這種軟件,確實是大恩了... 自己不行就找個行的唄,反正不差錢。
1、上策,找個行的。
2、中策,清理過期數(shù)據(jù),升級硬件
3、下策,自己慢慢玩,慢慢優(yōu)化。

TA貢獻1802條經驗 獲得超4個贊
@Mr.落葉: 技術債務都能短時間解決的話,那就不叫技術債務了。
誰不希望1小時解決問題啊,問題是問題就是需要幾個月或者幾年才能解決的咋辦?
先升級硬件,拖一拖,然后就拖成技術債務了,幾乎99%的人不會想著如何花時間做優(yōu)化,而不是增加功能的。
如果給你兩個選擇
一個月解決問題費用10萬,
一天解決問題費用100萬。
你會選擇哪個?

TA貢獻1802條經驗 獲得超10個贊
洗數(shù)據(jù)肯定會對db造成一定壓力的,但不建議你在一個存儲過程中搞完,你這樣搞可能會把正常業(yè)務給完全拖跪掉
正常的搞法是你前面通過分頁方式抽取卡id信息,通過程序一個個的對卡的數(shù)據(jù)進行查詢和更新,這種雖然看起來耗時更長,但對db壓力是最小的了

TA貢獻1818條經驗 獲得超7個贊
你說得對,我現(xiàn)在是備份的一個測試數(shù)據(jù)庫,就是想看有沒有辦法把這些數(shù)據(jù)控制在兩個小時內搞完,正式的可以等凌晨的時候批量更新了,那時候基本上沒人使用,影響不是特別大

TA貢獻1859條經驗 獲得超6個贊
@Mr.落葉: 我們這邊有些類似的數(shù)據(jù)變化就是采用我說的這種方式,mysql數(shù)據(jù)庫,洗完幾千萬數(shù)據(jù)也就2個多小時(而且還是在線)。
這塊你可以估一下,按照我的做法只要每秒能夠處理掉1k行數(shù)據(jù)2小時足夠了,這塊你只要確保填充幾個字段的查詢語句速度快,問題不大的。同時你可以在部署一個這樣的程序后看下db壓力,如果不大的話可以再部署一個加快處理速度(需要區(qū)分不同程序處理的數(shù)據(jù),比如簡單的卡號是否是偶數(shù))

TA貢獻2012條經驗 獲得超12個贊
update MemberShipCards A set A.總消費金額=sum(money) from?MemberConsumePayments p inner join?MemberConsums c
?on p.ConsumeId=c.Id?
inner join?MemberPayment m on p.PaymentId=m.Id where c.status=1 and m.paymenttype in(1,3,4,6,8) and c.memberCardid=A.xxxx
語法可能有誤,大體這樣,供參考
- 11 回答
- 0 關注
- 534 瀏覽
添加回答
舉報