一条静态SQL语句,请教SQL高手,执行结果诡异。
select * from LR where LRId in(
SELECT LR.LRId
FROM LR inner join groups on groups.groupid=lr.GroupId where
(GroupNo='ZHA140801C' and Amount= 3840) or
(GroupNo='ZHB140804A' and Amount= 5120) or (GroupNo='ZHS140805A ' and Amount= 6560) or
(GroupNo='ZHA140808C' and Amount= 5280) or (GroupNo='ZHA140811C ' and Amount= 3840) or
(GroupNo='ZHS140813A-1' and Amount= 9600) or (GroupNo='ZHS140813A' and Amount= 7920) or
(GroupNo='ZHS140816A' and Amount= 8880)
)
---其中GroupNo为Groups表中字段,唯一,Amout为LR表中字段,表示金额
问题
1、可能大家认为外围的Select是多余的,确实是的,本来是准备写Update的。但现在不管是不是多余,根据语法,我搞不懂为什么会出现以下的结果,结果如下:
2、in内部的Select单独执行时,搜索出9条LRId。
3、整个Select执行时,搜索出39条记录
4、修改表中数据的Amount,导致in内部的Select语句搜索记录为0条或1条....外围的Select仍旧为39条数据
我搞不懂到底问题出在哪儿
相关推荐
AMDP procedure 的结构与多结果集思路
摘要:本文深入解析了S/4HANA系统中AMDP(ABAP Managed Database Procedures)的核心语法与应用场景。AMDP通过将复杂计算下沉至数据库层执行,有效解决了数据搬运带来的性能瓶颈。文章重点剖析了AMDP方法实现的语法结构,包括PROCEDURE/FUNCTION声明、数据库绑定、语言选择等关键要素,并详细说明了USING子句对代码可维护性的影响。同时结合实际案例,展示了AMDP在模糊检索等业务场景中的性能优势,为ABAP开发者提供了清晰的AMDP开发指导。
SQL Server PIVOT实战:从静态到动态行转列与性能调优
在数据分析与报表开发中,行转列是高频需求。SQL Server通过PIVOT与UNPIVOT将明细数据按字段值横向展开为宽表,替代繁琐的SUM/CASE WHEN写法。本内容深入剖析PIVOT从静态到动态列的构建原理,覆盖QUOTENAME、FOR XML PATH列拼接、sp_executesql动态执行及临时表落库等实践,并探讨复合索引、执行计划对比等性能调优手段,以及UNPIVOT反透视和窗口函数取最新值的进阶用法。无论是BI报表还是数据仓库,掌握这些技巧能显著提升透视处理效率,降低维护成本。
深入解析MySQL SQL解析:从Lex词法分析到yacc语法构建
在数据库和编程语言领域,词法分析(Lex)与语法分析(yacc)是构建编译器前端的核心技术。Lex作为词法分析器生成器,负责将原始字符流转换为有意义的Token序列,例如识别SQL关键字、标识符和字面量;而yacc作为语法分析器生成器,则依据预定义的语法规则,将Token流组织成结构化的抽象语法树(AST)。这项技术的核心价值在于为领域特定语言(如SQL)提供精确的解析能力,确保语句的结构合法性。在数据库系统如MySQL中,Lex与yacc协同工作,构成了SQL查询从文本到可执行指令的转换基础。本文通过一个
从一次诡异的‘段错误’说起:你的Go/Rust二进制文件,到底链接了glibc还是musl?
本文探讨了Go/Rust二进制文件在glibc与musl libc兼容性问题中的表现,通过实际案例分析了因C库选择不当导致的段错误问题。文章详细介绍了glibc与musl的关键差异,提供了检测和构建完全静态二进制文件的实用方法,帮助开发者避免跨平台部署时的兼容性陷阱。
别再写`status != ‘‘`了!MyBatis中Integer=0被当成空字符串的诡异问题排查与最佳实践
本文深入分析了MyBatis动态SQL中Integer=0被当作空字符串处理的诡异问题,揭示了OGNL表达式引擎的类型转换陷阱。通过实际案例和解决方案,提供了防御式编程的最佳实践,包括安全判断写法、团队规范和架构级优化,帮助开发者避免类似生产事故。


