Power BI服务刷新追加查询报错：键未匹配表中任何行

核心疑问解答 #

1. 经过多步转换操作后能否追加表？
   完全可以。只要两张表在追加前的最终列结构（列名、数据类型、列顺序）完全匹配，不管中间经过多少删除、格式化、重命名操作，追加逻辑都能正常执行。桌面端正常说明转换后的列结构在本地是匹配的，但服务端可能因刷新时的元数据同步问题，出现列名/类型不匹配的隐性差异。

2. 两张表能否均每日刷新，还是需其中一张保持静态？
   两张表都可以每日刷新，无需任何一张保持静态。服务端报错和双表刷新无关，核心还是追加前的表结构一致性问题。需确保两张表在刷新后，转换步骤能稳定生成一致的列结构，避免因数据源返回的字段临时变化（比如SAP BW或Dataflow某次返回的列名/类型异常）导致结构不匹配。

3. 查询编辑器中的表查询顺序是否会影响加载顺序？该顺序是否会对追加查询产生影响？
   查询编辑器的列表顺序不影响实际加载/执行顺序。Power BI的查询执行是依赖驱动的——追加查询会自动先执行其依赖的两张源表的所有转换步骤，再执行追加操作。若存在循环依赖或步骤执行时机的隐性问题，桌面端也会报错，所以大概率不是此原因导致的服务端异常。

针对列名重命名相关问题的排查建议 #

• 固定重命名逻辑：避免使用“重命名为第一行的值”这类动态重命名方式，改用固定列名的重命名步骤（如Power Query中Table.RenameColumns(源, {{"旧列名1", "新列名1"}, {"旧列名2", "新列名2"}})），防止服务端刷新时数据源表头变化导致列名不匹配。
• 强制校验列结构：在追加步骤前，给两张表添加“保留列”步骤，明确指定要保留的列名和顺序，确保两张表的列完全一致，避免转换步骤中意外增减列导致结构差异。
• 统一数据类型：即使列名相同，数据类型（文本/数字/日期等）不一致也可能触发服务端报错（桌面端可能自动兼容）。在转换步骤末尾添加“更改类型”步骤，强制指定每列的数据类型。
• 查看服务端详细日志：在Power BI服务的「刷新历史」中查看完整报错日志，定位到具体是哪张表、哪个步骤出现的The key didn't match any rows in the table问题，排查服务端执行转换时与本地的差异。

内容的提问来源于stack exchange，提问作者worldwidegleb