如何在同一张表中基于文本关联更新列？现有SQL异常排查

• 模糊匹配逻辑和需求不匹配，存在多值匹配风险
  语句内的关联条件x.[Long Description] LIKE '%' + POtable.[Invoice Number] + '%'和预期规则偏差很大：
  1. 该写法代表“长描述任意位置包含发票号即匹配”，和需求里“待更新行的长描述以发票号结尾”的判定规则不一致，会产生大量误匹配
  2. 当同一条税务计提行的长描述能匹配到多条已填充Order no的PO记录时，自连接会生成多行匹配结果，UPDATE在多值匹配场景下的赋值是非确定性的，部分数据库会直接触发执行错误，导致语句中断
• 空值赋值的隐性破坏
  子查询使用LEFT JOIN关联POtable，当某条税务计提行没有匹配到任何带有效Order no的PO记录时，查询返回的originalpo字段值为NULL；这部分行因为id能和目标actuals行匹配上，会被直接带入UPDATE流程，把原本标记为'#'的Order no值覆盖为NULL，丢失原标记状态。
• 匹配规则的隐含偏差
  语句没有对发票号本身的包含关系做边界校验，如果PO表中存在前后嵌套的发票号（例如发票号INV01和INV012），那长描述末尾带INV012的计提行会同时匹配到两条PO记录，进一步加剧赋值混乱的问题；另外如果参与匹配的Invoice Number字段存在NULL值，拼接后的LIKE表达式结果为NULL，会被系统静默过滤，不会给出任何异常提示。
• 执行层面的性能隐患
  自连接使用带前导通配符的LIKE匹配，完全无法命中表上的现有索引，数据量稍大时就会触发全表扫描，不仅执行效率极低，还会因为锁范围过大、锁等待超时直接导致语句执行失败，这也是语句“并非每次都能正常执行”的典型诱因——并非逻辑完全错误，而是运行时超时被系统中断。
• 筛选逻辑的对齐偏差
  子查询对税务计提行的筛选没有和外层更新目标的筛选条件完全对齐，在部分数据库版本的执行计划优化下，可能出现谓词下推偏差，导致最终更新的目标行范围和预期不一致。

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