目录
[一、FROM 关联表](#一、FROM 关联表)
[二、WHERE 查询过滤条件](#二、WHERE 查询过滤条件)
[三、SELECT 字段列表](#三、SELECT 字段列表)
前言
今天实战开发刚好写到了复杂 SQL，突然想起前几天两位正在实习的同学分享的经历，这里用同学A和B称呼切入和大家聊聊。
A 在做数据库操作时候依赖鼠标可视化点击操作，结果把整个数据库都删了。然后带他的前辈强调：但凡涉及数据库的操作，绝对不要用鼠标，都要写 SQL 脚本执行 。我还记得他说好像并不是简单的点击失误，反正大家记住直接图形化鼠标操作数据库很危险就对了。
然后再说B被批评的这个经历，我感觉很多还在学习的小伙伴可能都有这个问题。他视频中坦诚交代了，之前学习的时候就没有太认真去敲代码，像SQL语句之类他都是AI写的。前段时间程序员岗位热潮，大家都强调了能看懂代码的重要性，所以B很多代码都没有自己认真写过。结果实习之后，他们公司明令禁止工作中使用 AI 写代码，主要是为了防止企业业务数据泄露。然后他说自己只能偷偷用 AI ，后来那天交付成果，直接被老板约谈批评了，AI 生成的 SQL字段命名错误、逻辑不符合业务预期、漏洞一大堆。B也是很诚实说了自己不会写SQL，他们老板人还不错的，说给他一个小时现在立马学会然后重新写一份。
说实话我之前对 SQL 也不够重视。看完他们的真实实习踩坑经历，才意识到手写 SQL、吃透语法逻辑的重要性。正好借这篇博文梳理复杂SQL书写逻辑。
我们要写的逻辑是查询所有商品详情。
一、FROM 关联表
思路：
写的思路从返回的实体类切入。
涉及到什么信息，就涉及到什么表。
明面上我们看出来要关联的表有：商品表、商品图片表、品牌表、规格表
然后我们再向里找，鼠标悬停看关联实体：
规格关联实体返回的是商品规格和规格项列表。我们这样就知道了要关联商品规格表 和规格项表。
这里有一个更简便的方法：
涉及到返回的是一个集合的，我们可以直接看数据库，把表名带关键字段的全部作为要关联的表。比如规格specification，我的数据库里关于specification表的有规格表，规格项表，商品规格表，这三个表就都需要关联。
类目关联实体里面的内容是类型。我们这样就知道了要关联商品类型表。（共三级类目，关联三次类型表）
这样我们就找到了所有要关联的表，总共七张，还有一张是要关联三次的。这个多找多写多体会就好了。
很好，我们写完了第一步。
这里字段列表我们一会要进行修改，先用*替一下。
写完了关联表，我们来写where过滤条件。
二、WHERE 查询过滤条件
这里强调一下 表设计规则 ：子表一定会存主表主键当外键。
每一张表都对应着一张牵连自己的表。顺着每一张关联表找关联，他们形成一个闭环。n张表就是n-1条过滤条件。
逻辑：
不难理解goods表一定是主表。我们切入去看。
主表外键可关联到的有四张表：brand，3个productType。这就对应了四条过滤条件。
我们划去 bz_brand，type1，type2，type3 四个表去看其他表，还有：bz_goods_image，bz_specification，bz_specification_option，bz_goods_specification_option，四个表。
很明显，bz_goods_image 和另外三个格格不入，去看它的外键，找它的外键是谁的主键，就和谁关联。
然后就三张规格表了，他们三个之间一定有关联，一伙处理。
他们仨不可能凭空产生关系，因为所有表关联都要勾搭上主表！！
所以我们去看这三个表，谁里包含的键值能勾搭上主表的主键，因为主表别的键都名花有主，只能是主键。
一看是bz_goods_specification_option。
很好，然后我们就像接龙一样，每一条首尾呼应，完成这三这张表的查询过滤，具体什么样看成品前三条🤓👇：
很清晰的对吧！
三、SELECT 字段列表
多表联查时，如果字段数量不多，可以直接使用*查询全部字段，不用手动写别名。
一旦出现字段重名冲突 （多张表存在同名字段，例如多张表都有id、name），就不能直接写*。 需要手动写明字段：表.字段 别名，AS关键字可以省略。
强调：
就算部分字段没有发生重名冲突，也建议全部显式写出，别名和实体属性保持一致，方便 MyBatis 做结果封装，避免映射错乱。
以上就是小编完成这个复杂SQL的所有思路，如有不完善处请评论区指出，感谢阅读❤