簡體   English   中英

MySQL更新表列基於其他兩個表中的值

[英]MySQL update table column based on values from two other tables

我有三個表:Guest,JournalEntry和EmailCore,其中包含以下相關列

JournalEntry (je)
------------------------------
id | guestId | emailId | store


EmailCore (ec)
----------
id | store


Guest (g)
----------
id | store

具有以下關系:

je.guestId -> g.id

je.emailId -> ec.id

我剛剛在JournalEntry表上添加了store列:

ALTER TABLE `JournalEntry` ADD `store` int(11) NOT NULL;

並且我正在嘗試使用以下規則將所有商店數據從EmailCore和Guest遷移到JournalEntry:

1)如果je.emailId不為null,則使用EmailCore中的商店

2)其他使用來賓店

我知道一個事實,JournalEntry中的每一行都會在EmailCore或Guest中有一個商店。

考慮到這一點,我嘗試了以下查詢:

-- Migrate the proper store number to the store column of JournalEntry
-- If present, EmailCore.store has priority
UPDATE JournalEntry je
LEFT JOIN Guest g on g.id = je.guestId
LEFT JOIN EmailCore ec on ec.id = je.emailId
SET je.store = COALESCE(ec.store, g.store);

該查詢的問題在於,它試圖構造一個由所有三個表(je,ec和g)構建的大表,並且我不斷用完內存,或者進程在完成之前鎖定,因此我必須重新啟動數據庫集群。 如果將行限制在50萬左右,我可以使查詢工作。 但是,JournalEntry包含約2000萬條記錄。

誰能想到更好/更快,更少內存的方式來完成此任務? 也許是for循環/過程。 歡迎任何建議。

您的性能問題可能是因為guestemail_core有多個匹配的行。 但是,如果沒有很多重復項,那么索引將有助於查詢:

create index idx_guest_id_store on guest(id, store);
create index idx_emailcore_id_store on emailcore(id, store);

但是,如果id已經是主鍵,那幾乎一樣。

如果由於連接而導致大量重復行,那么我首先建議進行兩次更新:

UPDATE JournalEntry je JOIN
       EmailCore ec
     on ec.id = je.emailId
    SET je.store = ec.store;

UPDATE JournalEntry je JOIN
       Guest g
       on g.id = je.guestId
    SET je.store = g.store;
WHERE je.emailid IS NULL;

然后,我將使用子查詢簡化這些操作:

UPDATE JournalEntry je
    SET je.store = (SELECT ec.store
                    FROM EmailCore ec
                    WHERE ec.id = je.emailId
                    LIMIT 1
                   );

UPDATE JournalEntry je
    SET je.store = (SELECT g.store
                    FROM Guest g
                    WHERE g.id = je.guestId
                    LIMIT 1
                   )
    WHERE je.emailid IS NULL;

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM