第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

請教一個sql server優(yōu)化的問題

請教一個sql server優(yōu)化的問題

收到一只叮咚 2018-12-06 16:42:03
最近遇到一個需求,要求在會員卡表增加幾個冗余字段,記錄該會員卡的最后消費時間,總消費金額(總消費金額分為現(xiàn)金,會員卡卡金,其中現(xiàn)金包括支付寶,微信和其他用戶自定義支付方式),總消費次數(shù),總充值金額,最后充值時間,總充值次數(shù)這么幾個冗余字段。目前分離出來的測試數(shù)據(jù)庫里面正常會員卡的總數(shù)是700萬左右,消費數(shù)據(jù)上億了(暫且就考慮為一億); 涉及到的數(shù)據(jù)表: MemberShipCards:會員卡表(700多萬條正常數(shù)據(jù)) MemberConsums:消費記錄表 MemberConsumePayments:消費記錄支付方式 MemberPayment:支付方式列表 MemberRecharges:充值數(shù)據(jù) 各個表之間的關聯(lián)關系是:MemberConsumes關聯(lián)了MemberShipCards(一張會員卡有多條消費記錄) MemberConsumePayments:這里面記錄了該會員卡結算的使用的結算方式,關聯(lián)在每條消費記錄上面的(MemberConsums),但是每一種結算方式又是對應在MemberPayment支付方式列表里面的,也就是說要查詢每張卡的現(xiàn)金支付總金額就要MemberShipCards,MemberConsums,MemberConsumePayments,MemberPayment聯(lián)合查詢,比如: select 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=xxxx 以上的sql語句就是查詢該會員卡總現(xiàn)金消費金額(支付金額是存儲在MemberConsumePayments 這里面的,而區(qū)別現(xiàn)金這個支付方式的在MemberPayment這里面,因為每張卡有很多的消費記錄,要篩選出正常狀態(tài)的,所以才有c.status=1?) 然后查詢出這個金額之后再根據(jù)會員卡id去修改會員表里面的冗余字段值 以上就是其中的一個查詢,目前我的實現(xiàn)邏輯是先把正常的會員卡id查詢出來放在臨時表里面,然后循環(huán)這個臨時表 select id=identity(int,1,1),Id as cardId into #cardsIds from MemberShipCards where [Status] = 1 CREATE INDEX IX_Id ON #cardsIds(Id) declare @count bigint declare @index bigint select @count = COUNT(id) from #cardsIds while(@count>=@index) begin   --具體邏輯,查詢和修改冗余字段   set @index+=1 end 注:各個查詢總和的字段和where條件都已建立索引,由于這里我用的是存儲過程循環(huán)600多萬條數(shù)據(jù),整個過程執(zhí)行完畢粗略估算大約耗時好幾個小時,這樣對于其他的查詢操作肯定受影響,由于本人sql功底有限,在此跪求各位大神為小弟提供一下解決方案,大恩不言謝
查看完整描述

11 回答

?
湖上湖

TA貢獻2003條經驗 獲得超2個贊

這個需求僅僅是基于數(shù)據(jù)庫中現(xiàn)有的記錄來計算這幾個冗余字段并更新到會員卡表?不用管以后發(fā)生新的消費時同步更新這些冗余字段?

?

如果是這樣,那簡單啊。性能差也不是問題,找數(shù)據(jù)庫壓力小的時候,一批批慢慢跑嘛,總能跑完的。

?

其實更大的問題是,這些中途增加的冗余字段的數(shù)據(jù)初始化搞定以后,怎樣才能伴隨這新的消費發(fā)生而同步更新的問題。這才是要命的大問題。

查看完整回答
反對 回復 2019-01-07
?
素胚勾勒不出你

TA貢獻1827條經驗 獲得超9個贊

會員卡700萬的這種軟件,確實是大恩了... 自己不行就找個行的唄,反正不差錢。

1、上策,找個行的。

2、中策,清理過期數(shù)據(jù),升級硬件

3、下策,自己慢慢玩,慢慢優(yōu)化。

查看完整回答
反對 回復 2019-01-07
?
子衿沉夜

TA貢獻1828條經驗 獲得超3個贊

這些都不能段時間內解決問題,找個專業(yè)的數(shù)據(jù)庫大神也不是那么容易的

查看完整回答
反對 回復 2019-01-07
?
慕虎7371278

TA貢獻1802條經驗 獲得超4個贊

@Mr.落葉: 技術債務都能短時間解決的話,那就不叫技術債務了。

誰不希望1小時解決問題啊,問題是問題就是需要幾個月或者幾年才能解決的咋辦?

先升級硬件,拖一拖,然后就拖成技術債務了,幾乎99%的人不會想著如何花時間做優(yōu)化,而不是增加功能的。

如果給你兩個選擇

一個月解決問題費用10萬,

一天解決問題費用100萬。

你會選擇哪個?

查看完整回答
反對 回復 2019-01-07
?
守候你守候我

TA貢獻1802條經驗 獲得超10個贊

洗數(shù)據(jù)肯定會對db造成一定壓力的,但不建議你在一個存儲過程中搞完,你這樣搞可能會把正常業(yè)務給完全拖跪掉

正常的搞法是你前面通過分頁方式抽取卡id信息,通過程序一個個的對卡的數(shù)據(jù)進行查詢和更新,這種雖然看起來耗時更長,但對db壓力是最小的了

查看完整回答
反對 回復 2019-01-07
?
qq_笑_17

TA貢獻1818條經驗 獲得超7個贊

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

查看完整回答
反對 回復 2019-01-07
?
BIG陽

TA貢獻1859條經驗 獲得超6個贊

@Mr.落葉: 我們這邊有些類似的數(shù)據(jù)變化就是采用我說的這種方式,mysql數(shù)據(jù)庫,洗完幾千萬數(shù)據(jù)也就2個多小時(而且還是在線)。

這塊你可以估一下,按照我的做法只要每秒能夠處理掉1k行數(shù)據(jù)2小時足夠了,這塊你只要確保填充幾個字段的查詢語句速度快,問題不大的。同時你可以在部署一個這樣的程序后看下db壓力,如果不大的話可以再部署一個加快處理速度(需要區(qū)分不同程序處理的數(shù)據(jù),比如簡單的卡號是否是偶數(shù))

查看完整回答
反對 回復 2019-01-07
?
瀟湘沐

TA貢獻1816條經驗 獲得超6個贊

給一個歪招。找一個不使用的冗余字段是能存json/xml的,把那幾個冗余字段當一個對象進行反序列化存在剛剛的字段里。這個改動應該比較小。

查看完整回答
反對 回復 2019-01-07
?
江戶川亂折騰

TA貢獻1851條經驗 獲得超5個贊

兄弟,你有點跑題了

查看完整回答
反對 回復 2019-01-07
?
繁花如伊

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

語法可能有誤,大體這樣,供參考

查看完整回答
反對 回復 2019-01-07
  • 11 回答
  • 0 關注
  • 534 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯(lián)系客服咨詢優(yōu)惠詳情

幫助反饋 APP下載

慕課網(wǎng)APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網(wǎng)微信公眾號