简介面向E10 ERP管理员的常用SQL语句集合聚焦系统上线后的持续改善场景覆盖PO待交明细、出入库统计、待领料清单、请购单价检查、物料采购分析、呆滞料计算、应付已付汇总、订单达交率与工单准时完工率等核心业务分析查询。压缩包内共包含50个文件以46个SQL脚本为主体辅以DOC/DOCX操作说明和PDF逻辑手册包体仅1.67MB便于下载与查阅。目前已有1184人学习适用于需要借助SQL深入核查数据、优化流程的ERP管理人员。除常用分析查询外还提供覆盖品号、仓库、工作中心、工厂信息、采购与销售信息、客户品号、工艺路线、供应商料件价格等主数据导入的后台脚本并附存储过程与逻辑说明文档可帮助管理员快速搭建初始化数据、减少重复手工处理。 做 ERP 实施这几年我最常被业务方问的一句话不是“系统怎么又报错了”而是“帮我在数据库里查一下这个数”。E10 这类 ERP 系统前台画面能覆盖日常八成的操作但剩下两成比如跨模块对账、历史数据追溯、异常单据定位、字段取值核查基本都得靠 SQL 直接查后台。我刚开始接手 E10 项目时光是找表就花了不少时间后来慢慢把日常高频查询整理成一套“查用 SQL 语句集合”按场景分类遇到问题直接翻开抄效率提升非常明显。这篇就把我自己项目里沉淀下来的 E10 查询脚本、表结构规律、排查思路和踩坑经验一起分享出来适合正在做 E10 实施、运维或二开的同学参考。1. 为什么我坚持维护一份“查用 SQL 集合”1.1 图形界面解决不了的三类问题E10 的前台报表和查询画面做得并不差但实际项目里总会遇到三类问题光靠点鼠标很难定位。第一类是数据对不上。库存报表和账面数差了几百件前台能看到总数但不知道差异到底来自哪笔单据订单交期被改了业务想知道改之前的值是什么前台画面早就覆盖掉了。第二类是流程卡住。单据卡在某个审核节点前台只显示“等待审核”但具体是谁、哪个角色、为什么没流下去前台查不到只能去后台单据表、审核记录表里翻。第三类是误操作修复。品号资料被重复建立、单号断号、BOM 被覆盖这些情况需要把原始数据捞出来比对确认到底是操作问题还是程序问题。这三类问题都有一个共同点必须通过 SQL 站在数据层面去还原现场。前台是业务视角后台才是数据真相手上有一套按场景整理好的脚本几分钟就能定位比现场临时翻表靠谱得多。1.2 这套集合的定位和使用边界我整理的这套 SQL 集合定位非常明确以查询为主主要解决“数据在哪里、怎么取、怎么判断”。它不是让你拿去直接改数据的虽然查询结果往往也会暴露出需要修正的数据但修正操作是另一套流程必须经过确认、备份、走改数申请。刚开始接触 E10 的同学可能会有一个误区以为拿到一套 SQL 就能到处跑、什么表都能查。实际上每套 E10 项目的库表结构多少都有差异版本不同、二次开发程度不同表名和字段名都可能不一样。所以我的脚本集合在开头就写清楚了表名和字段名的来源环境方便后续按实际库调整。这也是我一直强调的查询脚本只有建立在理解业务和表结构的基础上才真正有用否则就是一堆无法落地的代码片段。2. 先摸清 E10 的库表规律查表不再靠猜2.1 看命名规则少走一半弯路E10 的数据库结构我用了几套项目下来最大的感受是规律性很强。无论前端界面叫什么名字后台表基本都遵循几条约定。主档表和交易表分开。品号、客户、供应商、仓库这类基础资料一般在独立的主档表里表名和字段相对稳定而订单、工单、出入库单这类交易数据会拆成单头和单身两张表单头存公共信息比如单号、日期、客户、审核状态单身存明细信息比如品号、数量、单价、仓库。关联的时候用单号加单身序号这个结构非常像 Excel 里的“订单主表订单明细表”拆分只是强制用外键关联。关联字段也有规律。品号字段通常是 itm_no 或 item_no单号通常是 xxx_no日期通常是 xxx_date数量通常是 qty 或 qty_xxx。单身表一般会有一个序号字段比如 seq 或 itm_seq配合单号做联合主键。另外E10 还提供了一批视图名字往往以 V_ 或 View 开头视图里已经帮我们把常用关联做好了日常查询优先用视图能省掉大量 JOIN 操作。2.2 我日常高频使用的核心表清单下面这张表是我个人项目里高频使用的表结构示例属于简化后的通用模型。不同环境可能有差异但定位思路是一致的表名示例类型主要用途常用关联字段item_base主档品号基本资料品名、规格、状态itm_noitem_cat主档品号分类如原材料、半成品、成品cat_nocus_master / sup_master主档客户主档、供应商主档cus_no / sup_nobcm_master / bcm_detail单头单身BOM 表头与 BOM 单身bcm_nocms_order / cms_order_d单头单身客户订单及订单明细ord_nomoct_master / moct_detail单头单身工单/制造令及工单明细mo_nowh_master主档仓库档案wh_noinv_balance交易库存结余按仓库品号存放数量wh_no itm_noinv_trace交易出入库流水记录了每笔异动doc_no itm_noV_ITEM_STOCK视图视图常用于直接查库存、可用量itm_no / wh_no实际使用中我会先用系统自带的表字典或数据库工具大致浏览一下表清单把这种“主档表、单头单身表、汇总账表、流水账表”的分类框架搭出来后面不管碰到什么新查询都能快速判断应该去哪一层取数。就比如查库存先想清楚是要看当前结余汇总表还是看每一笔出入库流水表这决定了 SQL 怎么写。3. 高频查询场景与 SQL 参考3.1 基础资料查询品号、BOM、客户供应商基础资料查询是最常见的一般用于核对档案是否建重复、状态是否启用、BOM 用错料号这类问题。先看品号基本资料查询SELECT i.itm_no AS 品号, i.itm_name AS 品名, i.itm_spec AS 规格, i.status AS 状态, c.cat_name AS 分类 FROM item_base i LEFT JOIN item_cat c ON i.cat_no c.cat_no WHERE c.cat_name 原材料 AND i.status 1 ORDER BY i.itm_no;需要注意状态字段在不同版本里可能用 1/0、Y/N 或者 A/V/I 来表示不要想当然。我第一次写就是默认状态 1 代表有效结果把一批停用品号全带出来了还好只是自查。稳妥的办法是先 SELECT * 出来看一两行确认字段含义再正式写查询。BOM 是制造业项目里最容易出问题的资料查 BOM 时最核心的是把“单头单身品号名称”三层关系拉平。简化示例如下SELECT bm.bcm_no AS BOM编号, pm.itm_no AS 母件品号, pm.itm_name AS 母件品名, bd.itm_no AS 子件品号, bd.qty AS 单位用量, bd.unit AS 单位 FROM bcm_master bm JOIN item_base pm ON bm.parent_itm_no pm.itm_no JOIN bcm_detail bd ON bm.bcm_no bd.bcm_no WHERE bm.bcm_no BOM20240001 ORDER BY bd.seq;这类查询的关键是理解“母件-子件”关系。BOM 单据里单头存的可能是 BOM 编号、版本、母件品号单身存的是子件品号和用量一定不要把母件和子件的品号搞反了。查出来之后还可以把它和标准成本、替代料等表继续关联但新手阶段先把这张“平铺明细表”做好后面怎么加都顺。3.2 单据查询订单、工单、出入库流水单据查询的场景更多是“业务跟我反映某个单有问题我要把整单信息拉出来看”。以客户订单为例单头信息如订单号、客户、订单日期、审核状态单身信息如品号、数量、单价、交期全都放到一个结果集里SELECT o.ord_no AS 订单号, o.ord_date AS 订单日期, o.status AS 状态, c.cus_name AS 客户, od.itm_no AS 品号, od.qty AS 数量, od.price AS 单价, od.require_date AS 要求交期 FROM cms_order o JOIN cus_master c ON o.cus_no c.cus_no JOIN cms_order_d od ON o.ord_no od.ord_no WHERE o.ord_date 2024-01-01 AND o.status IN (1, 2) ORDER BY o.ord_no, od.seq;订单查询最容易掉的坑就是 JOIN 之后没有注意单头对单身是一对多。如果单头 JOIN 单身时把条件写漏了或者关联字段错误行数会成倍翻。我在 5.1 里会专门说这个现象。这里先记住一个自查习惯写完带 JOIN 的查询后先看返回多少行再用单头表的单号数量对比一下如果结果行数比单号数量多很多大概率是 JOIN 条件有问题或表关系没理清。工单或制造令的查询结构和订单几乎一样只是把订单表换成 moct_master / moct_detail关联字段换成工单号。出入库流水也是一样思路但要注意流水表往往有“单号单别品号”这种复合关系同一个品号在同一天可能有多笔异动查流水时务必带上仓库和异动类型字段否则很难定位具体是入库还是出库、是调拨还是盘点产生的。3.3 库存与在途把“量”拆清楚再写 SQL库存相关查询是 E10 项目里频率最高的也是最容易闹出“取数口径”问题的。我先列出两类常见需求一是查当前库存结余二是查在途订单。库存结余适合用汇总表因为在途量是用订单单身没入库的部分去推算的。SELECT w.wh_name AS 仓库, i.itm_no AS 品号, i.itm_name AS 品名, CONVERT(DECIMAL(18,3), SUM(b.qty)) AS 现有量 FROM inv_balance b JOIN item_base i ON b.itm_no i.itm_no JOIN wh_master w ON b.wh_no w.wh_no WHERE b.qty 0 GROUP BY w.wh_name, i.itm_no, i.itm_name ORDER BY w.wh_name, i.itm_no;查询结果集里保留品号和品名这个动作看起来多余但在后续核对 Excel 时非常有用少了品名层层透视的时候就只能看到一串品号非常痛苦。如果想看某个品号的“可用量”往往要结合在途量、预约量、冻结量等字段计算不同项目的口径不同。我的建议是先向业务确认口径再对着字段写公式不要自己编一个“安全库存现有量-在途量”拍脑袋定义。口径错了SQL 再漂亮也是白搭业务方拿你查出来的数去开会结果对不上信任感一次就没了。4. 让查询不卡壳的几个优化习惯4.1 慢查询排查先看执行计划再谈优化E10 项目一般都装在 SQL Server 上库表数据量上去后偶尔会遇到一个 SQL 跑几十秒甚至几分钟。这时候不能凭感觉加索引而是先用执行计划定位。SQL Server Management StudioSSMS里点“包括实际执行计划”再执行查询结果下方会出现执行计划图重点看几个地方有没有大表扫描Table Scan/Clustered Index Scan、有没有警告图标比如缺失索引提示、各个操作符的“估计行数”和“实际行数”偏差大不大。我习惯的排查顺序是先看能不能缩小 WHERE 范围比如时间字段别写一个特别宽的范围、别在条件里对字段做函数运算比如 WHERE YEAR(date_col)2024 会抑制索引使用再看 JOIN 的关联字段类型是否一致类型不一致极容易导致隐式转换进而全表扫描最后才考虑加索引。我自己踩过的坑是日期字段存成了 varchar写 BETWEEN 时看起来能查出来但完全走不了索引后来统一转成日期类型再比较查询时间从几十秒降到了几百毫秒。4.2 去重、空值与窗口函数的正确用法热门搜索词里经常出现“SQL 语句去重”“SQL 去除空值”“SQL 窗口函数”这几个技巧在 E10 查询里确实很常用。先说空值库存表、价格表经常有空字段处理时我优先用 ISNULL 或 COALESCE而不是在 WHERE 里写字段 因为 NULL 和空字符串完全不是一回事。比如查品号价格时没维护价格的品号可能为 NULL直接用 ISNULL 把它转成 0 再比较结果才完整。窗口函数是处理“取最新一笔”“按品号排名”这类需求的最佳选择。比如想找每个品号最近一次变更的价格记录SELECT itm_no, price, effective_date FROM ( SELECT itm_no, price, effective_date, ROW_NUMBER() OVER (PARTITION BY itm_no ORDER BY effective_date DESC) AS rn FROM item_price ) t WHERE t.rn 1;这套写法比 GROUP BY 灵活得多因为 GROUP BY 只能取分组字段和聚合函数结果想额外带出价格、生效日期这些明细字段就会很别扭。而 ROW_NUMBER() 唯一标识出同一品号下按日期排序的第几条记录再取 rn 1干净利落。类似的场景还有查找重复品号、重复 BOM 版本等都可以套这个模板。至于去重我只会用 DISTINCT 处理那种“探索性查询”正式跑数的 SQL 尽量避免它因为 DISTINCT 往往是掩盖 JOIN 重复问题的偷懒做法。如果查出来有重复先找清楚重复的根源到底是从哪张表扩出来的而不是图省事加个 DISTINCT否则这次是去重了下次换一个条件又错。5. 我踩过的坑常见问题与排查实录5.1 JOIN 查询结果翻倍最典型的一次是业务反馈“某订单单身明明只有 3 行查出来却有 12 行”。我顺手把 SQL 里所有 JOIN 的表列出来发现除了订单头、订单单身外还关联了客户主档和品号主档。客户主档和品号主档本应是一对一关系但客户表里有重复档案品号表里也有一模一样的品号重复建档结果 1订单对 3单身再对 2重复客户再对 2重复品号行数直接乘到了 12。排查方法很简单不 JOIN 客户和品号表先只看单头单身确认基础行数是 3然后一次加一个 LEFT JOIN每加一个就观察行数变化在哪一步翻了倍就是哪张表出了问题。这个经验后来我整理成一条法则JOIN 之前先确认每个关联字段在关联表里是不是唯一的不对应的先聚合好再关联尤其是在主档表上有重复资料时不要直接 JOIN。5.2 类型不一致与隐式转换有段时间我写库存查询特别慢反复优化索引都没效果。后来查看执行计划发现 WHERE 条件里字段是 varchar但参数我写成数值型SQL Server 自动做隐式转换导致该字段的索引失效。具体现象是条件写得越精确跑得越慢。后来统一用 CONVERT 或 CAST 把参数显式转成字段类型或者把字段重建为正确的数据类型问题才彻底解决。这个坑最容易出现在日期和单号字段上。E10 里有的版本日期字段是 datetime有的是 varchar单号字段基本是 varchar但导出到 Excel 后常被转成数值回查时如果用数值去匹配单号就会出现查到一半查不到的情况。我的习惯是任何外部输入的值先在查询前统一处理成明确的字符串再进 SQL能避免一大半诡异问题。5.3 排序规则冲突与跨库查询E10 项目有时候会把报表库和正式业务库分开跨库查询就成了常事。跨库 JOIN 时如果两个库的排序规则不一致会直接报“无法解决排序规则冲突”。第一次碰到时我以为是自己 JOIN 条件写错了检查半天发现是库级别排序规则不同。解决方案不复杂关联字段比较时在字段后面加 COLLATE DATABASE_DEFAULT强制使用当前库默认排序规则去比较。比如SELECT t1.itm_no, t2.itm_name FROM db_bak.dbo.item_old t1 JOIN item_base t2 ON t1.itm_no t2.itm_no COLLATE DATABASE_DEFAULT;另外还要提醒一下跨库、跨服务器查询前先确认账号是否有权限E10 生产库的账号一般不会给你太多权限不要尝试用 sa 账号连接风险极大出了问题说不清楚。5.4 安全底线查询语句别做成万能输入口最后说一个我给自己定的规矩。哪怕是查询脚本也绝不直接拼接外部输入值。很多同学喜欢把 SQL 集合做成带参数的功能比如在 Excel 里输一个品号就自动生成查询这个方向很好但实现时一定要用参数化查询而不是把用户输入直接拼进 SQL 字符串里。如果直接把输入值拼接进查询条件等于把 SQL 注入的风险亲手送到业务手里一旦有人输入特殊字符轻则查询报错重则数据遭殃。注意凡是把你整理好的 SQL 分享给别人使用时一定要用参数化查询、只读账号、最小权限并明确告知这些脚本只用于查数不做任何更新删除操作。这四个坑只是我踩过的一小部分。做 E10 数据库查询几年下来最大的心得不是背了多少表名而是建立了“先理解业务口径再梳理表关系最后写 SQL”的思维路径。每次从排查中写出一个新的查询脚本我会顺手在文档末尾追加一段备注写上库环境、执行时间、结果行数和踩坑点时间一长这套东西就不只是脚本集了更像一个项目知识库。平时带新人我也直接把这个文档丢过去让他们先照着查几天数基本就能独立应付大多数业务查询需求。如果你也在维护 E10 或其他 ERP 系统建议从今天就建一个这样的查用 SQL 集合哪怕只有十条八条也比每次临时翻表强得多。本文还有配套的精品资源点击获取