• <dd id="3gzlp"></dd>

    <li id="3gzlp"><acronym id="3gzlp"></acronym></li>

    <span id="3gzlp"></span>

    幾百萬上千萬數據的程序如果更新必定超時,請教大家都是怎么處理的

    靈風 發布于 04/23 18:57
    閱讀 3K+
    收藏 3

    精選30+云產品,助力企業輕松上云!>>>

    求大批量mysql數據處理的思路

    加載中
    2
    jim19770812
    jim19770812

    更新超時十之八九是事務太大

    1.要精簡代碼,讓事務變小

    2.加查詢條件索引,縮短更新時where條件的查詢時間

    3.如果有查詢,如果可以的話從事務里分離,在事務外面先算好,再開事務只處理更新

    4.幾百萬幾千萬的數據可以分批處理,比如一萬筆一次更新,這樣事務也小點,執行速度也會快點

    5.如果某個更新是非關鍵更新,比如更新個冗余字段比如點擊數之類的,可以異步去處理

    0
    rtgbvcd
    rtgbvcd

    用id更新,唯一主鍵

    0
    j
    junfei1888
    類似雙色球數據統計的代碼能寫嗎???
    haitaosoft
    haitaosoft
    smartwheel 都實現過。。。。
    0
    quietheart
    quietheart

    推薦思路步驟1.先見一個同等結構的更新表,然后用ETL進行抽取和更新處理,步驟2.確認更新表的數據沒有問題后將源表刪除,然后將更新表的表名改成源表表名即可

    0
    ychost
    ychost
    用內存表,orcale,sqlserver都支持的還不錯
    0
    壯志凌云111
    壯志凌云111

    多線程了解一下,不用謝

    0
    f
    freezingsky
    拆分成更小的事務,即,大事務范圍拆分多個小事務,或者,對于數據量大的情況,改為分批處理,再或者,同時結合以上兩種方式。
    xflcx1991
    xflcx1991
    好答案。
    0
    lipengxs
    lipengxs

    先得確定超時原因,是更新數據太多? 還是其他業務更新導致的死鎖,不同問題不同的應對方案。

    如果是數據太多,是否需要分批更新,是否可以先查詢然后根據id去批量跟新,是否需要增加索引等

    如果是死鎖,需要查看監控信息,看看是哪類業務導致死鎖,一次更新數據太多,如果dml并發高的很容易引起死鎖。

    0
    goder037
    goder037

    引用來自“jim19770812”的評論

    更新超時十之八九是事務太大

    1.要精簡代碼,讓事務變小

    2.加查詢條件索引,縮短更新時where條件的查詢時間

    3.如果有查詢,如果可以的話從事務里分離,在事務外面先算好,再開事務只處理更新

    4.幾百萬幾千萬的數據可以分批處理,比如一萬筆一次更新,這樣事務也小點,執行速度也會快點

    5.如果某個更新是非關鍵更新,比如更新個冗余字段比如點擊數之類的,可以異步去處理

    yes

    0
    majiajue
    majiajue

    消息隊列來處理排隊

    返回頂部
    頂部
    聚看影院