SQL系列1:AI排查SQL语句中的幽灵

今天在开发过程中遇到一个奇怪的问题,两个一模一样的SQL语句一个执行正常,一个执行报错,我一个字母一个字母排查,也没发现两个语句有啥区别,于是将其抛给AI帮我答疑解惑。

结果AI分分钟都不用就给指出了错误所在:

我一眼就看出来问题了!

这两条 SQL 肉眼看着一模一样,但实际上有一个 看不见的隐藏字符导致一条报错、一条正常!

核心结论(100% 确定)

两条语句的唯一区别:LIKE 前面的空格不一样!

  • SQL1"c_ApplyCode" LIKE 中间是 全角空格 / 特殊空白字符 → PG 不识别 → 报错
  • SQL2"c_ApplyCode" LIKE 中间是 正常半角空格 → PG 识别 → 执行正常

为什么会这样?

你大概率是从 Word / 网页 / 不同编辑器复制粘贴 带来了看不见的非法字符

  • 全角空格  
  • 零宽空格
  • 制表符
  • 其他不可见特殊符号

PG 语法只认标准半角空格,不认任何奇怪空白符,所以直接报语法错。


给你 100% 纯净、可运行的 PG 原版语句

复制代码
SELECT "c_ApplyCode"
FROM "GZ_ToolUseRecord"
WHERE "c_ApplyCode" LIKE (
    SELECT '%'||"c_SValue"||'%'
    FROM "AA_Basic_EncodingRulesDetails"
    WHERE "c_CodeName"='工装申领单号' AND "i_Sequence"='1'
)
ORDER BY "c_ApplyCode" DESC;

快速验证方法(你自己就能测)

  1. 把报错那条 SQL 里 LIKE 前面的所有空格删掉
  2. 重新敲一个普通空格
  3. 再执行 → 立刻正常!

最终总结

两条 SQL 逻辑完全一样,唯一差别:空格字符不同!

删掉重输空格就解决了。

这几个SQL语句是在新换的笔记工具Obsidian上编辑完复制到KingFusion低代码平台上的,导致了这个莫名奇妙的错误,看来以后代码可以复制到Obsidian上备份,但最好不在其中编辑,避免出现类似问题。

相关推荐
Elastic 中国社区官方博客14 分钟前
使用 Elasticsearch 作为 Grafana 的直接替代 Prometheus 后端
大数据·数据库·sql·elasticsearch·搜索引擎·grafana·prometheus
杨婷12320 分钟前
2026 企业微信会话存档服务商选型指南:一维助手方案深度解析
大数据·数据库·企业微信
2601_963771371 小时前
Optimizing Logistics and Transportation Sites on WordPress
前端·数据库·windows·php
AC赳赳老秦1 小时前
采购专员自动化:OpenClaw 自动比价、生成询价单、跟踪供应商报价进度实战指南
开发语言·数据库·人工智能·python·自动化·github·openclaw
蚁库1 小时前
Oracle 11g RAC 多路径配置总搞不定?iSCSI + Multipath + ASM 磁盘组,14节视频带你完整通关
数据库·oracle
C++ 老炮儿的技术栈1 小时前
MFC 自定义纯色居中文字进度条控件
c语言·数据库·c++·windows·算法·c·visual studio
灯澜忆梦1 小时前
【MySQL1】| DDL 数据定义语言
数据库·sql·mysql
2601_963771372 小时前
Speeding Up Creative Agency Portfolios: A Performance Guide
前端·数据库·php
运维大师2 小时前
【安全与故障排查】03-【复盘】数据库被入侵:从发现到溯源全过程
数据库·安全·adb
Quincy_Freak3 小时前
银河麒麟 SQLite 实操:Excel 导入与 SQL 语法编辑功能详解摘要
数据库·arm·数据库管理·大数据分析·银河麒麟·aarch64·sqlitego