SAP数据导入方案全解析：Direct Input与BDC实战指南

上个月刚帮一个客户做了物料主数据批导的优化，把原来跑了三个小时的Session直接干到二十分钟以内，顺手还处理了一批陈年没执行的死Session。这种活干多了你会发现，SAP里的数据导入方案看着一大堆，实际上绕来绕去就是两条主线：标准 Direct Input 程序，以及 BDC 批输入。用对了，一天导几万条主数据都不是事；用不对，一个Session卡在SM35里半个月没人敢动。

这篇文章不聊虚的，就把它拆开讲明白：两者底层差别、标准程序清单、选型逻辑、实战代码套路，还有我这些年真正踩过的坑。适合正在做数据迁移、接口开发、月结数据导入的ABAP开发，也适合刚接触批导的业务顾问快速建立认知。

1. 先搞清楚：Direct Input 和 BDC 到底差在哪

1.1 名字看着像，底层是两套系统

很多刚接触这块的人会把Direct Input和BDC混为一谈，实际上它们在SAP里是两套完全不同的机制。

Direct Input（直输程序）是SAP标准交付的批量维护程序，通过文件读取数据，内部调用标准模块或直接更新表。它的特点是单条记录的处理效率高、标准校验逻辑完整，因为它是SAP自己写的，天然知道哪些表要一起更新、哪些校验要做。典型的事务码包括：SM30（表维护生成器）、OABL（资产批量导入）、OBWI（库存初始化）、RFBIDE00（会计凭证导入）、RFBIKR00（客户主数据导入）、RFBIKM00（供应商主数据导入）等等。

BDC（Batch Data Communication，批输入通信）则是一种模拟用户屏幕操作的技术。它的原理非常简单粗暴：先通过SHDB录制事务的屏幕操作流程，然后把录下来的屏幕序列保存成数据集，通过程序把业务数据逐字段填入屏幕字段，驱动SAP执行和手工操作一模一样的逻辑。BDC又分为两种落地方式：Call Transaction（直接调用）和 Session（会话批输入）。

如果拿生活里的事情类比：Direct Input就像你请了一个熟悉内部流程的管家，你跟他说“把这些单子录入掉”，他自己知道怎么分类、怎么走审批；BDC则像一个复读机，你录了一段点击操作，它照着点了成百上千次。管家用的是脑子和内部权限，复读机用的是肌肉记忆。

理解这个区别有什么用？直接决定了你的容错设计。BDC模拟屏幕录入，所以它“看到”的屏幕和真实用户看到的一样，屏幕变体变了、字段顺序变了、版本升级后界面变了，BDC就会失灵；而Direct Input是走后门直接更新底层数据，响应快、稳定性高，但对数据格式要求严格，一个字段不对就会整条回滚。

1.2 BDC的两种落地方式：Session和Call Transaction

BDC的两种执行方式，在选型时经常让人纠结，我先把它们的核心差异列出来：

实操中的经验是：数据量超过5000条就别用Call Transaction主跑，哪怕是后台Job也建议用Session。原因不是Call Transaction跑不了，而是大量同步调用会让SAP的对话工作进程长时间占用，严重影响其他用户的操作体验。Session的好处是提交后立即释放进程，由系统后台任务慢慢消化。

1.3 标准批输入程序清单与适用场景

这部分是纯干货，我按业务模块梳理一下常用的标准批输入入口，方便你接到需求时快速定位：

请记住，这些只是“最常用”的一份清单。SAP在不同行业方案里还塞了大量专用批导事务码，比如零售的WSOB、银行业的某个专用导入器、CRM里的数据迁移工作台等等。接到项目时第一件事不是打开SE38写程序，而是先在SPRO或者事务码里搜一下有没有现成的批输入入口——这个习惯能帮你省掉大量无谓的开发。

2. 选型逻辑：什么时候用标准程序，什么时候自己写BDC

2.1 有现成的标准程序/导入工具时，优先用现成的

这句话我在不同场合反复强调：做数据导入的第一原则是“能不开发就不开发”。标准Direct Input程序经过了全球成千上万家客户的洗礼，逻辑完备性和校验严格程度远超你的自研代码。举个例子，资产导入用OABL，它内部会处理资本化日期、折旧码有效性、成本中心一致性检查，这些逻辑如果你用BDC模拟AS01去录，屏幕校验一道不少，但事务码本身可能没有Deep Update那么强的后台一致性检查。

所以接到批导需求，我的判断顺序是：

1. 有没有BAPI？ 优先用BAPI，因为BAPI是官方支持的支持“事务性调用”的接口，能自己处理COMMIT和ROLLBACK，并且返回消息结构化（RETURN表）。
2. 有没有标准批输入程序？ 比如资产主数据OABL、会计凭证RFBIDE00、库存OBWI，这些文件格式规定得清清楚楚，照着拼文本就行。
3. 有没有LSMW标准方法？ LSMW里提供了BAPI、录屏、IDoc、Direct Input等多种导入方法，而且有图形化界面，适合业务顾问自己搞。
4. 最后才考虑自制BDC或RFC接口。 例如某些事务码压根没有BAPI（比如某些特殊的配置类T-code），或者BAPI版本过老缺失关键字段，这时候才值得考虑自己写BDC。

2.2 BAPI、IDoc、LSMW与BDC的边界

很多项目上的ABAP问过我：既然BAPI那么好，为什么还要学BDC？这个问题很现实——因为BAPI不是万能的。

BAPI是从业务对象模型里暴露出来的标准API，它的覆盖面远远落后于事物码。SAP每年发布那么多增强字段，很多新加的字段进了屏幕，但BAPI要等后续版本才支持，甚至有些专用场景根本没有BAPI（比如某些行业解决方案里的审批字段、扩展字段组合）。这时候你只能二选一：要么增强BAPI，要么绕道BDC。

IDoc和BDC也不是替代关系。IDoc是EDI/ALE体系里的数据交换载体，适合跨系统异步传输；BDC更适合单系统内的大批量数据录入。LSMW则是SAP官方的“录屏器”，它本身不生产数据，而是把文件数据映射到BAPI、录屏或者Direct Input等方法上。你可以把LSMW理解成一个低代码平台，它底层还是BDC或者BAPI在跑。

2.3 决定选型的几个硬指标

抛开场景谈选型都是耍流氓，我在评估一个批导需求时，会先问四个问题：

第一，业务数据的容错度如何？ 导客户主数据，错一条就得全停，因为客户主数据涉及销售、财务、信用多个视图，一错百错；导日志型数据（比如某些流水表），允许跳过错误记录继续跑，后续统一处理。容错度低的用Call Transaction逐条判断+收集错误，容错度高的可以放心用Session批量跑。

第二，实时性要求多高？ 财务月结期间你要通过批导补凭证，用户不可能等着；但是如果是后台夜批的数据同步，实时性就没那么敏感。实时性要求高的场景，直接在程序里Call Transaction，报错即时返回；能接受延迟的，走Session后台上Job。

第三，数据量到底多大？ 我见过不少项目把几千条数据用LSMW慢慢跑，结果LSMW里的录屏方法每跑几百条就莫名卡死，最后改用标准批导程序十分钟搞定。数据量超过一万条时，优先考虑标准程序或自定义程序+批次提交，避开录屏式BDC的低效问题。

第四，长期维护性。 自研BDC高度依赖屏幕布局，如果项目后面要升级S/4 HANA，屏幕变化会让你的BDC全部作废。所以在S/4升级项目上，我通常会建议客户在批导技术选型时向BAPI/IDoc方向靠拢，哪怕多些开发成本，也值。

3. 实战套路：一个完整的BDC批导项目怎么做下来

3.1 录制与代码生成的细节

假设你最终决定走BDC路线，第一步当然是SHDB录制。这个操作看起来简单，但有几处细节直接影响后续开发效率。

录制时把业务操作的每个屏幕都完整走一遍，不要为了省事跳过中间步骤。尤其是带确认弹窗的（比如保存后弹出消息框），你会看到录制列表里多出几个OK代码，这些在后期调试时都是干扰项。另外一个关键点是：录制时多用F2、F4这类功能键，少用鼠标点击。鼠标点击产生的是位置信息，录进BDC表里容易因为分辨率或Fiori主题发生变化而失效；功能键是语义化的操作，兼容性更好。

录制完成后，SHDB菜单栏里有“程序”->“生成程序”选项，可以直接生成一个带bdcdata表的示例ABAP程序。生成的代码里会包含这样的核心片段：

abap复制DATA: BEGIN OF bdcdata OCCURS 0.
        INCLUDE STRUCTURE bdcdata.
DATA: END OF bdcdata.

DATA: BEGIN OF messtab OCCURS 0.
        INCLUDE STRUCTURE bdcmsgcoll.
DATA: END OF messtab.

这个结构是玩BDC的家庭作业，必须烂熟于胸：bdcdata表的每一行，要么是一条PROGRAM + DYNPRO + DYNBEGIN（表示开始新屏幕），要么是一条FNAM + FVAL（表示给某个屏幕字段赋值）。屏幕切换信号是通过一个特殊的dynbegin标记实现的，代码里通常写成：

abap复制CLEAR bdcdata.
bdcdata-program = 'SAPMV45A'.
bdcdata-dynpro = '0101'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.

注意dynbegin = 'X'是屏幕启动的标识，它告诉SAP“现在要开始处理KNA1相关的屏幕0101了”。这一行之后的FNAM/FVAL赋值，全都作用于这个屏幕上的字段。

3.2 bdcdata表构建的三种写法

不同水平的程序员写出的bdcdata构建代码差别巨大，我把常见的三种写法都列一下，并说清楚各自适合什么场景。

写法一：逐条APPEND，最直观，适合字段少的事务

abap复制CLEAR bdcdata.
bdcdata-program = 'SAPMF02D'.
bdcdata-dynpro = '0100'.
bdcdata-dynbegin = 'X'.
APPEND bdcdata.

CLEAR bdcdata.
bdcdata-fnam = 'KNA1-KUNNR'.
bdcdata-fval = lv_kunnr.
APPEND bdcdata.

这种写法一眼能看懂，屏幕字段名直接写在代码里。缺点是当字段数量多（几十个）时，代码会拉得很长，而且字段名如果写错（比如KNA1-KUNNR写成了KNA1-KUNNR多了个空格），执行时根本报不出来，只会显示“字段不存在”之类的系统错误。

写法二：用内表循环生成，适合模板化批量场景

abap复制LOOP AT gt_mapping INTO gs_mapping.
  CLEAR bdcdata.
  bdcdata-fnam = gs_mapping-fieldname.
  bdcdata-fval = gs_mapping-fieldvalue.
  APPEND bdcdata.
ENDLOOP.

这种思路是把字段名和值做成配置表或程序内部定义的映射表，代码里不再硬编码字段名，方便后续维护和复用。但注意：屏幕上必输字段不能漏。如果你按映射表循环赋值，遗漏了某个必输项，BDC执行时会在这里停下等待用户输入，导致会话挂起。

写法三：混合式，最推荐，适合复杂落地

abap复制FORM build_screen_0100 USING p_kunnr TYPE kunnr
                            p_name1 TYPE name1.
  CLEAR bdcdata.
  bdcdata-program = 'SAPMF02D'.
  bdcdata-dynpro   = '0100'.
  bdcdata-dynbegin = 'X'.
  APPEND bdcdata.

  PERFORM bdc_field USING 'KNA1-KUNNR' p_kunnr.
  PERFORM bdc_field USING 'KNA1-NAME1' p_name1.
ENDFORM.

FORM bdc_field USING p_fnam TYPE bdcdata-fnam
                     p_fval TYPE bdcdata-fval.
  CLEAR bdcdata.
  bdcdata-fnam = p_fnam.
  bdcdata-fval = p_fval.
  APPEND bdcdata.
ENDFORM.

把字段赋值封装成子过程的好处是，你可以对每个字段做值转换、Trim空格、补零，还可以统一记录哪些字段被赋过值。这套写法我用了很多年，不管字段多少都清晰。

3.3 CALL TRANSACTION 的调用与消息收集

数据构建完成后，调用方式决定了体验。下面是Call Transaction的经典骨架：

abap复制CALL TRANSACTION 'FD02' USING bdcdata
   MODE   'A'
   UPDATE 'S'
   MESSAGES INTO messtab.

参数解释一下：

• MODE：'A'表示显示所有屏幕（相当于前台演示），'E'表示仅出错时显示屏幕，'N'表示后台静默执行不显示任何屏幕。实际批导肯定用'N'或'E'。
• UPDATE：'S'是同步更新，等数据库操作完成才返回；'A'是异步更新，先提交LUW再异步执行后续更新。批导用'S'最稳妥。
• MESSAGES INTO：把执行过程产生的所有消息（包括S、E、W类型）写入内表，这就是你的错误日志来源。

返回之后，判断成功与否的标准写法是：

abap复制READ TABLE messtab WITH KEY msgtyp = 'E' TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
  " 有错误消息，这条数据没导入成功
ELSE.
  " 没有E类型消息，基本就算成功了
ENDIF.

需要特别提醒：不要只检查SY-SUBRC。CALL TRANSACTION的SY-SUBRC返回0只表示事务执行没有异常终止，不代表业务校验通过了。比如你录入了重复的客户号，屏幕弹出一个警告（W级别消息），SY-SUBRC照样是0，但数据其实没进去。所以判断成功与否，必须综合SY-SUBRC + 消息类型。

如果你希望每条数据独立提交，可以顺手加上：

abap复制IF lv_no_error = abap_true.
  COMMIT WORK.
ELSE.
  ROLLBACK WORK.
ENDIF.

但注意，如果BDC内部已经做了数据库提交（某些标准的批导程序会自己COMMIT），外层再COMMIT就没什么意义了。这个要结合具体事务码的更新模式判断，没有统一答案。

3.4 用Session方式落地的管理经验

Session方式的开发套路和Call Transaction在bdcdata构建上完全一样，区别只在最后一步是调用BDC_INSERT函数把数据和屏幕序列打包成一个会话：

abap复制CALL FUNCTION 'BDC_INSERT'
  EXPORTING
    tcode     = 'FD02'
  TABLES
    dynprotab = bdcdata.

然后去SM35就能看到一条新会话记录，可以立即执行，也可以定时后台跑。要注意几点：

1. 每调用一次BDC_INSERT产生一条Session。如果数据有十万条，你不可能只插入一个十万条的Session，因为系统对单个Session的数据量有默认限制（通常几万行没问题，太多容易内存溢出）。更规范的做法是每500条或1000条插一个新Session，拆分成多个并行处理。
2. Session的执行必须在SM35里手动或通过SM36 Job触发。如果用户在SM35里点了“前台处理”，所有屏幕都会弹出来，那画面太美我不敢看（而且会锁表）。所以上线执行前，务必确认执行模式选的是“仅错误显示”或“后台处理”。
3. Session执行时，系统会重新打开一次标准屏幕处理逻辑。这意味着，就算你在程序里做了字段的填空、默认值处理，到了Session执行阶段，标准校验还是会再跑一遍。这是好事，它能兜底；但也是坏事，如果屏幕上有必输字段你没填，它会在那个环节卡住，挂成红色会话。

4. 避坑指南：批导现场踩过的坑

4.1 并发与重复数据：最隐蔽的坑

批导最怕的不是报错，而是“不报错但数据重复”或者“并发插入互相覆盖”。

先说重复数据。BDC模拟用户操作，如果来源文件里同一主数据出现了两遍，且程序没有在业务层面做唯一性校验，那么BDC会按照正常用户操作一样创建两条记录。SAP里的主数据唯一性大多数在业务逻辑层，不在数据库层，所以这种重复往往很难提前发现。我的做法是在批导前单独写一个预检程序：统计来源数据里的关键字段（客户号、物料号、资产号）的重复次数，超过1的直接打标记，不进入BDC流程。

再谈并发覆盖。多个Job并行插入会话，可能会因为同一行数据被多条会话并发处理而产生锁等待、UPDATE DEADLOCK。这些错误会直接导致那一批会话全部失败。解决方案是拆Session时给每个Session定一个明确的业务维度（比如按公司代码拆、按物料类型拆），确保同一个业务对象的操作串行发生。

4.2 Session卡死和堆积的处理

SM35里飘红的会话，几乎是每个做过批导的人都经历过的噩梦。卡死通常有两类原因：

• 有必输字段没填：屏幕校验过不去，但内容又不足以报Fatal错误，于是系统把状态停留在那里等你输入。这种会话在SM35里显示为红色，双击进去就能看到卡在哪个屏幕。
• 更新进程挂了：批量会话执行到一半，后台的更新进程出了问题，导致整个会话都无法前进。

处理这类问题的顺序是：先在SM35里选中卡住的会话，尝试“删除”或“重新处理”。如果删不掉，可能是因为会话被后台作业锁定了，此时检查SM37里有没有正在跑的后台Job，先把Job取消。如果删除了还好，大不了重导；如果卡住的会话堵住了后续会话，后面所有的会话都会排队等更新进程，这时候就需要在SM35里把后面的会话也清理掉，腾出系统处理能力。

真实场景里还有一种“假卡死”：数据量太大，而且全是长文本或附件型字段，Session执行时内存持续增长，导致更新进程长时间无响应。这种情况看起来像卡死，实际上还在跑，你只需要等待，或者通过ST05/ST22检查是否有长时间运行的SQL。

4.3 屏幕变体与版本变化导致BDC失效

BDC的天敌是屏幕变化。做过S/4升级项目的朋友应该深有体会：原来的ECC里跑得飞快的BDC，搬到S/4后各种报错——要么是屏幕字段找不到了，要么是字段名变了，要么是用户出口的行为变了。

没升级也没关系，光是一个屏幕变体就能让你头痛。比如销售订单创建的事务码VA01，用户做了一个屏幕变体把批次字段隐藏了，然后你的BDC用VA01录屏时录进去的屏幕布局跟变体布局不一致，执行时就会出“字段状态不匹配”的提示，导致会话错误。

这类问题的通用解决方案是：

1. 录制时尽量使用不带用户特定变体的默认屏幕；
2. 程序里赋值时，对每个字段做存在性检查，不存在的字段就不assign；
3. 如果系统里存在多个变体且无法统一，建议BDC调用前固定使用同一个变体，或者改用SU3用户的参数文件来控制屏幕字段状态。

再补一个容易被忽略的点：带长文本、表格控件（Table Control）的屏幕录制出来的BDC极其脆弱。因为Table Control的行数、滚动位置都会影响字段定位。遇到这种场景，我一般会先去搜BAPI或直接更新表结构，能不走BDC就不走。实在绕不开，处理表格控件时，每行都要注意STEAM标识的填写，否则系统分不清你是在给第几行赋值。

4.4 错误消息与调试定位技巧

BDC调试，说难也难，说容易也容易。核心思路是：把BDC的执行过程还原成屏幕序列，然后用调试器去看屏幕数据。

当你执行CALL TRANSACTION后出现E类型消息，但消息文本笼统（比如“字段XXX的输入不正确”），这时候最好用的工具是ST05（SQL跟踪）或者直接进入调试模式看执行的屏幕流。不过更快的定位方法是：

1. 把MODE设为'E'，让出错的那条记录把屏幕显示出来，你直接用肉眼去看它的字段状态——哪个字段是黄色必输、哪个字段值明显不对，一目了然。
2. 在BDC表里加一行特殊的OK字段，用BDC_OKCODE传递回车/保存，检查一下是不是漏了确认动作。很多录制生成的程序里都包含OKCODE的赋值，复制时容易漏掉中间步骤的确认键。
3. 打开SM35的“会话概览”，双击错误消息跳转到底层消息程序中去查看messtab里的多行内容——有时候真正的错误藏在第三条消息里，前两条只是警告。

另外，调试时有个小技巧：把bdcdata表的每一行内容直接显示到ALV里，人工核对一遍屏幕字段顺序。很多BDC失败是因为bdcdata表的行顺序不对——先写了下一个屏幕的字段，再写了当前屏幕的字段，导致系统把后一个字段当成当前屏幕的输入，自然报“字段不存在”或“字段输入不正确”。

5. 实际场景中的扩展：从批导到集成

5.1 SD销售订单与信用决策场景的批导

销售订单导入是一个高频场景。标准方案通常用BAPI_SALESORDER_CREATEFROMDAT2，但如果你需要带信用管理相关字段，或者要控制信用决策（对应热词里的“SD记录的信用决策”），BAPI的字段覆盖就可能不够。这时候我会在BAPI的基础上做扩展，或者走BDC录VA01带信用视图的路径。

但这里有个特别需要注意的点：信用检查是异步的。VA01里你创建订单时，系统可能只是标记了一个信用状态，真正的信用检查在保存时或后续通过OVAK之类的报表跑批完成。如果你用BDC模拟VA01录入后直接快速进入下一单，系统可能还没完成信用评估，导致后续信用控制报表数据不对。这种情况我一般会用BAPI，因为BAPI提供同步的信用检查参数，能直接返回信用相关的错误消息。

5.2 采购订单与物料凭证场景的处理

采购订单的批导同样面临BAPI字段不足的问题。热词里的“SAP采购订单设置必输”也是一个常见的坑：某些自定义字段（比如供应商确认字段、运输条款）在ME21N的屏幕上是必输，但标准BAPI不支持，用BDC录屏倒是能填进去。

这里还有一个容易混淆的点：物流中调用WS_DELIVERY_UPDATE可以过账发货并生成物料凭证，这个函数本身不是BDC，而是一个标准的BAPI风格函数。如果你需要批导“过账发货”这个动作，直接用这个函数常常是最稳定的路径，不需要去录VL02N的屏幕。很多搞不清楚批导选型的人，一看到物料凭证就下意识去录VL02N，其实用BAPI能少踩一半的坑。

5.3 物料BOM与产品层次的联动维护

BOM批导是PP模块里的高发问题区。SAP有标准BOM批导程序CS_BOM_MAINTAIN相关的一系列BAPI（如BAPI_BOM_CREATE），但如果你是维护一个“产品层次+CVBOM”的组合结构，传统的BOM导入只覆盖了BOM本身，产品层次（Product Hierarchy）里的销售视图字段可能需要额外的方式维护。

这个场景我给客户的建议通常是拆成两段：第一段用BAPI维护物料主数据及销售视图（含产品层次字段），第二段用CS_BOM系列的BAPI维护BOM结构。如果因为特殊字段两个BAPI都覆盖不了，再考虑走录屏式BDC。这里再次印证那个核心原则：先标准、后扩展、最后BDC。

5.4 金融与资产模块批导的特殊性

资产模块的批导，OABL是绕不开的话题。资产导入不仅涉及主数据（AS01/AS02），还涉及折旧、余额结转。OABL的文件格式比较死，很多项目在期初上线时资产数据不全或格式不规范，导致导入反复失败。我的建议是：导资产之前先跑预校验——把文件里的资产编号、成本中心、利润中心、折旧表这些主数据全部检查一遍，确保它们在被导入系统中都已存在，否则OABL会在中途挂起。

金融模块的批导则更敏感，比如财务凭证导入（FB01/FB02）。RFBIDE00是SAP标准的会计凭证批输入程序，它要求文件格式非常规范，包括公司代码、科目、金额、税码等。如果文件里带了一堆自定义字段（比如利润中心段、WBS元素段、成本中心段），标准程序往往支持得不够灵活，这时很多人会走上自研BDC录FB01的老路。我的经验是：对于这种带了CO/PS段字段的凭证导入，优先看SAP是否提供了增强点（BADI）来补充字段，不要一上来就录屏；因为银行对账单、发票校验、成本分配这类高频导入，SDN社区里已经有大量成熟方案，你照搬改进远比自己造轮子稳得多。

6. 关于批导程序开发的一些个人建议

最后再分享几段我这些年做批导的体会，算不上什么惊天动地的技巧，但确实能帮你少走不少弯路。

第一，批导代码一定要做日志。 很多人用Call Transaction跑完数据，只看了一个最终的成功计数就交差，这对业务人员来说完全不够。业务同事需要知道每一行数据到底成功没成功、失败原因是什么、原始文件里的哪一列对应出错字段。所以我的批导程序里，每条数据都会写一条日志到Z表，包含来源行号、关键字段、消息类型、消息文本、时间戳。这个表不光是给业务看，也是给未来的自己看——三个月后你说不清当时这批数据怎么来的，有了日志就能解释一切。

第二，别迷信录屏生成器的代码。 SHDB一键生成的代码只能作为起点，绝对不能直接上生产。生成的程序里通常没有文件读取、数据转换、重复校验、错误恢复这些逻辑，直接跑等于裸奔。我见过最离谱的案例是把生成器产生的代码原样套了个DO循环就去跑数据，结果表里的金额字段直接把小数点丢了（因为屏幕字段是字符型，内部格式和外部格式的转换根本没做）。

第三，批导程序的性能瓶颈通常不在ABAP，而在数据库和锁。 数据量大时，不要一条一条SELECT数据库，能用FOR ALL ENTRIES批量取就批量取；也不要让批导程序长时间持有数据库锁，能提交就及时提交（注意LUW边界）。

第四，一定要做幂等设计。 批导跑崩了，修复数据后重跑，是家常便饭。如果你的程序不做幂等控制，重跑一次就产生一批重复数据，那才是真的灾难。在写批导之前就想清楚：主数据靠什么字段判断唯一？业务数据靠什么单据号或外部参考号防止重复？把这些逻辑写进程序里，比事后手工清理数据要省一万倍的心。

第五，也是最重要的一条：永远预留一个“试运行模式”。 批导程序上线前，先用一小部分样例数据跑一遍，不真正提交数据库，只输出“模拟成功”的结果和日志。这一步能发现绝大多数字段映射错误和格式问题，避免直接污染生产数据。很多项目的批导翻车，都是因为跳过了试运行这个环节，拿全量数据直接顶上，结果一跑全是错——那时候你哭都来不及。