內(nèi)存消耗分析

• 查看內(nèi)存消耗

  • 管理控制臺(tái)提供整個(gè)實(shí)例的內(nèi)存消耗情況，即多個(gè)節(jié)點(diǎn)的內(nèi)存匯總值，詳情請(qǐng)參見Hologres管控臺(tái)的監(jiān)控指標(biāo)。

  • 慢Query日志中memory_bytes字段提供單個(gè)Query的內(nèi)存消耗情況，是非精確的值，存在一定的誤差，詳情請(qǐng)參見慢Query日志查看與分析。

• 內(nèi)存水位高

  可以通過Hologres管控臺(tái)的內(nèi)存使用率和實(shí)例內(nèi)存分布使用率指標(biāo)了解實(shí)例的內(nèi)存綜合使用率，詳情請(qǐng)參見Hologres管控臺(tái)的監(jiān)控指標(biāo)。當(dāng)內(nèi)存水位長(zhǎng)期超過80%，可以認(rèn)為屬于內(nèi)存水位高的情況。Hologres的內(nèi)存資源采用預(yù)留模式，即使沒有執(zhí)行查詢操作，也會(huì)有部分Meta、Index元數(shù)據(jù)和Cache加載到內(nèi)存中，該類元數(shù)據(jù)用于提升計(jì)算速度，無任務(wù)運(yùn)行時(shí)內(nèi)存使用率可能會(huì)到達(dá)30%~50%左右，屬于正常現(xiàn)象。內(nèi)存使用率持續(xù)升高，甚至接近100%，通常會(huì)影響系統(tǒng)的運(yùn)行，影響實(shí)例的穩(wěn)定性和性能。關(guān)于該問題產(chǎn)生的原因、主要影響和解決方法具體如下：

  • 產(chǎn)生原因

    • 元數(shù)據(jù)占用內(nèi)存多

      表現(xiàn)為Meta內(nèi)存使用率高：表數(shù)據(jù)量增加，數(shù)據(jù)總量也隨之增加，元數(shù)據(jù)占用內(nèi)存多，當(dāng)沒有任務(wù)運(yùn)行時(shí)，內(nèi)存水位也會(huì)高，通常建議一個(gè)Table Group下不要超過10000張表（包括分區(qū)子表，不包含外部表），Table Group的Shard數(shù)高，也會(huì)造成更多的文件碎片和積累更多的元數(shù)據(jù)，占用元數(shù)據(jù)內(nèi)存。

    • 計(jì)算內(nèi)存高

      表現(xiàn)為Query內(nèi)存使用率高：運(yùn)行任務(wù)時(shí)掃描大數(shù)據(jù)量或者計(jì)算邏輯非常復(fù)雜，例如有非常多的Count Distinct函數(shù)、復(fù)雜的Join操作、多字段Group By、窗口操作等。

  • 主要影響

    • 影響穩(wěn)定性

      當(dāng)存在元數(shù)據(jù)過大等問題時(shí)，會(huì)超額占據(jù)正常Query可用的內(nèi)存空間，導(dǎo)致在查詢過程中，可能會(huì)偶發(fā)SERVER_INTERNAL_ERROR、ERPC_ERROR_CONNECTION_CLOSED、Total memory used by all existing queries exceeded memory limitation等報(bào)錯(cuò)。

    • 影響性能

      當(dāng)存在元數(shù)據(jù)過大等問題時(shí)，會(huì)超額占據(jù)正常Query可用的緩存空間，從而導(dǎo)致緩存命中減少，Query延遲增加。

  • 解決方法

    • 元數(shù)據(jù)過多導(dǎo)致內(nèi)存較高時(shí)，建議通過hg_table_info表對(duì)數(shù)據(jù)表進(jìn)行治理，詳情請(qǐng)參見表統(tǒng)計(jì)信息查看與分析。建議刪除不再查詢的數(shù)據(jù)或者表和減少不必要的分區(qū)表設(shè)計(jì)，以釋放占用的內(nèi)存。

    • 計(jì)算導(dǎo)致內(nèi)存水位較高時(shí)，建議區(qū)分寫入和查詢場(chǎng)景，進(jìn)行SQL優(yōu)化，詳情請(qǐng)參見如何解決查詢時(shí)OOM和如何解決導(dǎo)入導(dǎo)出時(shí)OOM。

    • 擴(kuò)容，對(duì)實(shí)例的計(jì)算和存儲(chǔ)資源進(jìn)行升配，詳情請(qǐng)參見實(shí)例列表。

識(shí)別OOM報(bào)錯(cuò)

Total memory used by all existing queries exceeded memory limitation. 
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100

報(bào)錯(cuò)解讀如下。

• queries=(2031xxxx,184yy)

  指queries=(query_id,query使用的內(nèi)存)，例如queries=(2031xxxx,18441803528)，代表query_id=2031xxxx的Query，在運(yùn)行時(shí)單個(gè)節(jié)點(diǎn)使用了18 GB的內(nèi)存。異常信息里面會(huì)列出消耗內(nèi)存的Top 5的Query，可以通過報(bào)錯(cuò)找到內(nèi)存消耗最大的Query，并在慢Query日志查看與分析中查看詳細(xì)的Query信息。

• Used/Limit: xy1/xy2

  指單個(gè)節(jié)點(diǎn)使用的計(jì)算內(nèi)存/單個(gè)節(jié)點(diǎn)的計(jì)算內(nèi)存上限，單位為Byte。單個(gè)節(jié)點(diǎn)使用的計(jì)算內(nèi)存是指當(dāng)前時(shí)刻所有Query運(yùn)行時(shí)在該節(jié)點(diǎn)使用的計(jì)算內(nèi)存總和。例如Used/Limit: 33288093696/33114697728，代表所有Query在該節(jié)點(diǎn)運(yùn)行時(shí)的內(nèi)存使用了33.2 GB，但是單個(gè)計(jì)算節(jié)點(diǎn)的彈性內(nèi)存只能配33.1 GB，因此出現(xiàn)OOM。

• quota/sum_quota: zz/100

  quota代表資源組，其中zz對(duì)應(yīng)資源組分配的資源。例如quota/sum_quota: 50/100代表設(shè)置了資源組，其分配的資源是實(shí)例總資源的50%。

產(chǎn)生OOM的基本原因

有的系統(tǒng)在內(nèi)存資源不足時(shí)會(huì)采用磁盤緩存的方式進(jìn)行算子降級(jí)（Spill to Disk），Hologres為了保障查詢的效率，默認(rèn)所有算子都采用內(nèi)存資源進(jìn)行計(jì)算，因此會(huì)存在內(nèi)存不足導(dǎo)致OOM的問題。

內(nèi)存的分配和上限

一個(gè)Hologres實(shí)例是由多個(gè)節(jié)點(diǎn)組成的分布式系統(tǒng)，不同的實(shí)例規(guī)格對(duì)應(yīng)不同的節(jié)點(diǎn)數(shù)，詳情請(qǐng)參見實(shí)例規(guī)格概述。

在Hologres中一個(gè)節(jié)點(diǎn)的規(guī)格是16 Core 64 GB，即內(nèi)存上限是64 GB，一個(gè)Query運(yùn)行時(shí)涉及到的任意節(jié)點(diǎn)的內(nèi)存不足，都會(huì)產(chǎn)生OOM異常。內(nèi)存會(huì)分幾個(gè)部分，包括Query計(jì)算、后端進(jìn)程、緩存、Meta等部分。在早期版本中，計(jì)算節(jié)點(diǎn)（Worker Node）的內(nèi)存上限是20 GB，但Hologres從V1.1.24版本開始，計(jì)算節(jié)點(diǎn)運(yùn)行時(shí)內(nèi)存取消單節(jié)點(diǎn)20 GB的限制，采用動(dòng)態(tài)調(diào)整節(jié)點(diǎn)內(nèi)存，定期檢查內(nèi)存水位，如果元數(shù)據(jù)較少時(shí)，會(huì)盡量將剩余可用內(nèi)存都分配給查詢運(yùn)行時(shí)使用，盡量保證運(yùn)行時(shí)內(nèi)存最大化分配，保障Query獲得足夠內(nèi)存分配。

如何解決查詢時(shí)OOM

• 當(dāng)出現(xiàn)查詢OOM時(shí)，其原因通常有如下幾類。

  • 執(zhí)行計(jì)劃錯(cuò)誤：統(tǒng)計(jì)信息不正確、Join Order不正確等。

  • Query并發(fā)度高，且每個(gè)Query消耗的內(nèi)存很大。

  • Query本身復(fù)雜或者掃描的數(shù)據(jù)量很大。

  • Query中包含union all，增加執(zhí)行器的并行度。

  • 設(shè)置了資源組，但是給資源組分配的資源較少。

  • 數(shù)據(jù)傾斜或者Shard Pruning導(dǎo)致負(fù)載不均衡，個(gè)別節(jié)點(diǎn)的內(nèi)存壓力較大。

• 以上原因的具體分析以及相應(yīng)的解決方法如下。

  • 資源組分配的資源較少

    使用Serverless Computing功能執(zhí)行查詢。Serverless Computing功能可以實(shí)現(xiàn)在實(shí)例獨(dú)享資源之外，使用Serverless資源執(zhí)行相關(guān)查詢。相比實(shí)例獨(dú)享資源，Serverless Computing提供更豐富的計(jì)算資源，并且查詢之間不會(huì)相互爭(zhēng)搶資源，因此非常適合解決內(nèi)存溢出（OOM）問題。Serverless Computing介紹，詳情請(qǐng)參見Serverless Computing概述，其使用方式詳情，請(qǐng)參見Serverless Computing使用指南。

  • 檢查執(zhí)行計(jì)劃是否合理

    • 類型1：統(tǒng)計(jì)信息不準(zhǔn)確

      通過執(zhí)行explain <SQL>可以查詢執(zhí)行計(jì)劃，如下圖所示rows=1000表示缺少統(tǒng)計(jì)信息或者統(tǒng)計(jì)信息不準(zhǔn)確，會(huì)導(dǎo)致生成不準(zhǔn)確的執(zhí)行計(jì)劃，從而使用更多的資源進(jìn)行計(jì)算造成OOM。

      解決方法如下。

      • 執(zhí)行analyze <tablename>命令，更新表的統(tǒng)計(jì)信息。

      • 設(shè)置AUTO ANALYZE自動(dòng)更新統(tǒng)計(jì)信息，詳情請(qǐng)參見ANALYZE和AUTO ANALYZE。

    • 類型2：Join Order不正確

      當(dāng)兩個(gè)表通過Hash算子執(zhí)行連接時(shí)，合理的連接方式是數(shù)據(jù)量較小的表構(gòu)建Hash表。通過執(zhí)行explain <SQL>命令查看執(zhí)行計(jì)劃，如果數(shù)據(jù)量更大的表在下方，小表在上方時(shí)，表示使用更大的表構(gòu)建Hash表，這種Join Order容易導(dǎo)致OOM。Join Order不正確的原因通常如下。

      • 表未及時(shí)更新統(tǒng)計(jì)信息，例如下圖中上面的表沒有更新統(tǒng)計(jì)信息，導(dǎo)致rows=1000。

      • 優(yōu)化器未能生成更好的執(zhí)行計(jì)劃。

      解決方法如下。

      • 對(duì)參與Join的表都執(zhí)行analyze <tablename>命令，及時(shí)更新統(tǒng)計(jì)信息，使其生成正確的Join Order。

      • 執(zhí)行analyze tablename命令之后，Join Order還是不正確，可以通過修改GUC參數(shù)進(jìn)行干預(yù)。如下所示設(shè)置optimizer_join_order=query，使優(yōu)化器按照SQL的書寫順序確定Join Order，適用于復(fù)雜Query。

        SET optimizer_join_order = query;
        SELECT * FROM a JOIN b ON a.id = b.id; -- 會(huì)將b作為HashTable的build side

        同時(shí)也可以根據(jù)業(yè)務(wù)情況，調(diào)整Join Order策略。

        參數(shù)	說明
        set optimizer_join_order = <value>	優(yōu)化器Join Order算法，values有如下三種。 query：不進(jìn)行Join Order轉(zhuǎn)換，按照SQL書寫的連接順序執(zhí)行，優(yōu)化器開銷最低。 greedy：通過貪心算法進(jìn)行Join Order的探索，優(yōu)化器開銷適中。 exhaustive（默認(rèn)）：通過動(dòng)態(tài)規(guī)劃算法進(jìn)行Join Order轉(zhuǎn)換，會(huì)生成最優(yōu)的執(zhí)行計(jì)劃，但優(yōu)化器開銷最高。

    • 類型3：Hash表預(yù)估錯(cuò)誤

      當(dāng)有Join操作時(shí)，通常是會(huì)把小表或者數(shù)據(jù)量小的子查詢作為Build Side構(gòu)建Hash表，這樣既能優(yōu)化性能，又能節(jié)省內(nèi)存。但是有時(shí)候因?yàn)椴樵冞^于復(fù)雜，或者統(tǒng)計(jì)信息的問題，數(shù)據(jù)量會(huì)估錯(cuò)，就導(dǎo)致把數(shù)據(jù)量大的表或者子查詢做了Build Side，這樣一來，構(gòu)建Hash表會(huì)消耗大量的內(nèi)存，導(dǎo)致OOM。

      如下圖所示，執(zhí)行計(jì)劃中Hash (cost=727353.45..627353.35 , rows=970902134 width=94) 即為Build Side，rows=970902134就是構(gòu)建Hash表的數(shù)據(jù)量，若是實(shí)際表數(shù)據(jù)量比這個(gè)少，說明Hash表預(yù)估不準(zhǔn)確。

      解決方法如下。

      • 查看子查詢的表是否更新統(tǒng)計(jì)信息或者統(tǒng)計(jì)信息是否準(zhǔn)確，若是不準(zhǔn)確，請(qǐng)執(zhí)行analyze <tablename>命令。

      • 通過以下參數(shù)關(guān)閉執(zhí)行引擎對(duì)Hash表的預(yù)估。

        說明

        該參數(shù)默認(rèn)關(guān)閉，但是可能在某些調(diào)優(yōu)場(chǎng)景被打開過，若是查看時(shí)打開的，可以進(jìn)行關(guān)閉。

        SET hg_experimental_enable_estimate_hash_table_size =off;

    • 類型4：大表被Broadcast

      Broadcast是指將數(shù)據(jù)復(fù)制至所有Shard。僅在Shard數(shù)量與廣播表的數(shù)量均較少時(shí)，Broadcast Motion的優(yōu)勢(shì)較大。在Join場(chǎng)景中，執(zhí)行計(jì)劃先進(jìn)行Broadcast，即將Build Side的數(shù)據(jù)廣播完再構(gòu)建Hash表，這就意味著每個(gè)Shard內(nèi)構(gòu)建Hash表的數(shù)據(jù)都是Build Side的全量數(shù)據(jù)，若是Shard多或者數(shù)據(jù)量較大，則會(huì)消耗很多內(nèi)存，造成OOM。

      假如表數(shù)據(jù)量是8000萬行，如下圖執(zhí)行計(jì)劃所示，預(yù)估表只有1行，參與Broadcast只有80行，與真實(shí)情況不符合，真實(shí)執(zhí)行時(shí)需要8000萬行數(shù)據(jù)參與Broadcast，導(dǎo)致消耗過多內(nèi)存從而出現(xiàn)OOM。

      解決方法如下。

      • 檢查執(zhí)行計(jì)劃中預(yù)估行數(shù)是否正確，不正確的話，請(qǐng)執(zhí)行analyze tablename命令更新統(tǒng)計(jì)信息。

      • 通過以下GUC關(guān)閉Broadcast，直接改寫為redistribution算子。

        SET optimizer_enable_motion_broadcast = off;

  • Query并發(fā)大

    監(jiān)控指標(biāo)上QPS增加明顯，或者OOM中報(bào)錯(cuò)：HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); 且每個(gè)Query使用的內(nèi)存較少，說明當(dāng)前Query并發(fā)較大，可以通過以下方式解決。

    • 若是有寫入，可以降低寫入并發(fā)，詳情請(qǐng)參見如何解決導(dǎo)入導(dǎo)出時(shí)OOM。

    • 采用主從實(shí)例讀寫分離部署（共享存儲(chǔ)）。

    • 擴(kuò)容實(shí)例計(jì)算規(guī)格。

  • 復(fù)雜Query

    若是Query本身比較復(fù)雜或者掃描數(shù)據(jù)量較多，一個(gè)Query就出現(xiàn)OOM，可以通過以下方法解決。

    • 計(jì)算前置，將清洗好的數(shù)據(jù)寫入Hologres，避免在Hologres進(jìn)行大型ETL操作。

    • 增加過濾條件。

    • SQL優(yōu)化：例如使用Fixed Plan、Count Distinct優(yōu)化等，詳情請(qǐng)參見優(yōu)化查詢性能。

  • UNION ALL

    如下所示，當(dāng)SQL中含有大量UNION ALL subquery時(shí)，執(zhí)行器會(huì)并行處理每個(gè)subquery，導(dǎo)致內(nèi)存壓力變大，從而出現(xiàn)OOM。

    subquery1 UNION ALL subquery2 UNION ALL subquery3 ...

    可以通過如下參數(shù)強(qiáng)制執(zhí)行器串行，減少OOM情況，但查詢速度會(huì)變慢。

    SET hg_experimental_hqe_union_all_type=1;
    SET hg_experimental_enable_fragment_instance_delay_open=on;

  • 資源組配置不合理

    OOM時(shí)出現(xiàn)報(bào)錯(cuò)：memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100。其中zz的取值較小，如下圖所示為10，說明資源組只擁有實(shí)例10%的資源。

    解決方法：重新設(shè)置資源組配額，每個(gè)資源組都不應(yīng)該小于30%。

  • 數(shù)據(jù)傾斜或Shard Pruning

    當(dāng)實(shí)例整體內(nèi)存水位不高，但仍然出現(xiàn)OOM的情況，一般原因?yàn)閿?shù)據(jù)傾斜或者Shard Pruning導(dǎo)致某個(gè)或者某幾個(gè)節(jié)點(diǎn)的內(nèi)存水位較高，從而出現(xiàn)OOM。

    說明

    Shard Pruning是指通過查詢剪枝技術(shù)，只掃描部分Shard。

    • 通過以下SQL排查數(shù)據(jù)傾斜，hg_shard_id是每個(gè)表的內(nèi)置隱藏字段，表示數(shù)據(jù)所在的Shard。

      SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id;

    • 從執(zhí)行計(jì)劃查看Shard Pruning，例如執(zhí)行計(jì)劃中Shard Selector為l0[1]，說明只選中了一個(gè)Shard數(shù)據(jù)進(jìn)行查詢。

      -- 這里distribution_key為x, 基于x=1過濾條件,可以快速定位所在Shard
      SELECT count(1) FROM bbb WHERE x=1 GROUP BY y;

      

    解決方法如下。

    • 設(shè)計(jì)合理的Distribution Key避免數(shù)據(jù)傾斜。

    • 若是業(yè)務(wù)有數(shù)據(jù)傾斜，需要對(duì)業(yè)務(wù)進(jìn)行改造。

  • 大基數(shù)多階段GROUP BY

    從Hologres V3.0版本開始，對(duì)于大基數(shù)的多階段Agg，當(dāng)GROUP BY的列與數(shù)據(jù)分布不匹配（Distribution Key不是GROUP BY Key的子集）時(shí)，低階段Agg的每個(gè)并發(fā)實(shí)例都會(huì)維護(hù)一張很大的Hash Table做GROUP BY Key聚合，導(dǎo)致內(nèi)存壓力很大，容易OOM。可以通過設(shè)置如下參數(shù)分階段去進(jìn)行Agg操作。

    -- 通過guc設(shè)置Agg HashTable行數(shù)的上限，如下SQL表示partial_agg_hash_table最多時(shí)8192行。默認(rèn)值為0，表示不限制。
    SET hg_experimental_partial_agg_hash_table_size = 8192;

如何解決導(dǎo)入導(dǎo)出時(shí)OOM

導(dǎo)入導(dǎo)出OOM是指數(shù)據(jù)在Hologres表之間導(dǎo)入導(dǎo)出，也包括內(nèi)部表和外部表之間導(dǎo)入導(dǎo)出，常見于MaxCompute導(dǎo)入到Hologres時(shí)出現(xiàn)OOM。

• 使用Serverless Computing功能執(zhí)行導(dǎo)入導(dǎo)出

  Serverless Computing功能可以實(shí)現(xiàn)在實(shí)例獨(dú)享資源之外，使用Serverless資源執(zhí)行相關(guān)導(dǎo)入導(dǎo)出任務(wù)。相比實(shí)例獨(dú)享資源，Serverless Computing提供更多的計(jì)算資源，并避免了任務(wù)之間的資源爭(zhēng)搶，非常適合解決內(nèi)存溢出（OOM）問題。Serverless Computing概述請(qǐng)參見Serverless Computing概述，其詳細(xì)使用方法請(qǐng)參見Serverless Computing使用指南。

• 大寬表或者寬列且有高Scan并行度

  通常在MaxCompute導(dǎo)入場(chǎng)景會(huì)出現(xiàn)大寬表或者比較寬的列有比較大的Scan并行度，導(dǎo)致寫入出現(xiàn)OOM。可以通過以下參數(shù)控制導(dǎo)入并行度減少OOM。

  • 大寬表導(dǎo)入（常用場(chǎng)景）

    說明

    以下參數(shù)與SQL一起執(zhí)行（優(yōu)先選擇前兩個(gè)參數(shù)，若是仍然出現(xiàn)OOM，可以適當(dāng)調(diào)低參數(shù)取值）。

    -- 設(shè)置訪問外部表時(shí)的最大并發(fā)度，默認(rèn)為實(shí)例的Core數(shù)，最大為128，不建議設(shè)置大，避免外部表Query（特別是數(shù)據(jù)導(dǎo)入場(chǎng)景）影響其它Query，導(dǎo)致系統(tǒng)繁忙導(dǎo)致報(bào)錯(cuò)。該參數(shù)在Hologres V1.1及以上版本中生效。
    SET hg_foreign_table_executor_max_dop = 32;
    
    -- 調(diào)整每次讀取MaxCompute表batch的大小，默認(rèn)為8192。
    SET hg_experimental_query_batch_size = 4096;
    
    -- 設(shè)置訪問外部表時(shí)執(zhí)行DML語句的最大并發(fā)度，默認(rèn)值為32，針對(duì)數(shù)據(jù)導(dǎo)入導(dǎo)出場(chǎng)景專門優(yōu)化的參數(shù)，避免導(dǎo)入操作占用過多系統(tǒng)資源，該參數(shù)在Hologres V1.1及以上版本中生效。
    SET hg_foreign_table_executor_dml_max_dop = 16;
    
    -- 設(shè)置MaxCompute表訪問切分split的數(shù)目，可以調(diào)節(jié)并發(fā)數(shù)目，默認(rèn)64MB，當(dāng)表很大時(shí)需要調(diào)大，避免過多的split影響性能。該參數(shù)在Hologres V1.1及以上版本中生效。
    SET hg_foreign_table_split_size = 128;

  • 比較寬的列有比較大的Scan并行度

    若是已經(jīng)調(diào)整過大寬表的導(dǎo)入?yún)?shù)，但是仍然出現(xiàn)OOM，可以排查業(yè)務(wù)是否有比較寬的列，若有可以通過調(diào)整以下參數(shù)解決。

    -- 調(diào)整寬列的shuffle并行度，減少寬列數(shù)據(jù)量的堆積
    SET hg_experimental_max_num_record_batches_in_buffer = 32;
    
    -- 調(diào)整每次讀取MaxCompute表batch的大小，默認(rèn)8192。
    SET hg_experimental_query_batch_size=128;

• 外部表數(shù)據(jù)重復(fù)

  若是外部表包含大量重復(fù)數(shù)據(jù)，會(huì)導(dǎo)致導(dǎo)入速度變慢或出現(xiàn)OOM。重復(fù)數(shù)據(jù)是相對(duì)而言，并沒有統(tǒng)一標(biāo)準(zhǔn)，例如有1億行數(shù)據(jù)，有8000萬行數(shù)據(jù)都是重復(fù)的，則認(rèn)為重復(fù)數(shù)據(jù)較多，請(qǐng)根據(jù)實(shí)際業(yè)務(wù)情況進(jìn)行判斷。

  解決方法：導(dǎo)入之前先對(duì)數(shù)據(jù)進(jìn)行去重再進(jìn)行導(dǎo)入或者分批次導(dǎo)入，避免一次性導(dǎo)入大量重復(fù)數(shù)據(jù)。