1. 项目解读单表查询里最不起眼却最要命的两个运算符先聊点实在的。很多人学SQLSELECT和FROM写完就觉得自己会查数据了结果一到实际需求就卡住什么“查价格打了八折后还大于一百的商品”“找库存低于五十的畅销书”“把订单金额加上运费后排序”这些其实都是单表内就能解决的事但第一步就栽在运算符上。这个项目“单表数据记录查询”把算术运算符和比较运算符单独拎出来讲我之前带新人时也喜欢这么设计教学顺序。原因很简单单表查询是理解数据库查询逻辑的起点而运算符是查询条件里最核心的砖块。你不用先懂多表、不懂索引只要把一张表里的算术计算、大小比较搞明白后面学JOIN、子查询、聚合函数都会顺畅得多。反过来如果运算符这关没过后面写出的SQL基本都是碰运气——看着结果对了换一批数据就崩。这个内容适合谁刚接触数据库的学生、准备面试但基础不牢的开发者、还有那些常年只写SELECT * 但想真正掌握条件查询的普通业务人员。说白了它是把“能跑”变成“跑得对”的一道分水岭。我在这篇文章里会把两个运算符的底层逻辑、执行顺序、边界情况、常见坑全部拆开讲并且配一个完整的模拟项目来实际操作一遍。看完之后你再回去写带WHERE条件的查询会明显感觉心里有底。2. 核心概念与整体设计思路2.1 为什么运算符是查询条件的“判断中枢”先建立一个整体认知。SQL查询的本质是“从表中选择满足条件的行”。而“满足条件”这个判断动作就是靠运算符完成的。单表查询的完整结构是SELECT 输出列 FROM 表名 WHERE 行筛选条件 ORDER BY 排序条件 GROUP BY 分组条件 HAVING 组筛选条件大多数人以为WHERE只是“写上字段、写个等号、写个值”但实际上WHERE后面紧跟的是一组逻辑表达式这些表达式由数据列、运算符、常量值共同构成。数据库引擎会逐行读取表中的数据对每一行分别计算这个表达式的结果看它为真还是为假。这个逐行扫描判断的过程就是查询的执行模型。算术运算符负责“计算出一个数值”比较运算符负责“判断两个值的大小或是否相等”。两者经常配合出现比如“计算折扣价后再判断是否落在某个价格区间”。单独学其中一个都不难但组合起来使用才是真实业务场景。我见过很多初学者写出这样的代码SELECT * FROM products WHERE discount_price 100;如果表中只有原价字段没有折扣价字段这个查询直接报错。正确做法是SELECT * FROM products WHERE price * 0.8 100;这里就同时用到了算术运算符乘和比较运算符大于。所以学运算符不只是认识符号更要理解它们可以嵌在表达式里嵌在WHERE条件的各个角落。2.2 运算符在单表查询中的“分工协作”我们把这套运算符放进实际查询任务里来看它们的协作方式。拿某书店的图书库存表为例表结构大概长这样book_id图书编号book_name书名category分类price定价stock当前库存sales已销售量现在要完成几个典型需求需求一列出“价格打八折后仍大于80元”的书。这个需求要求先对price做算术运算再与80做比较。SQL写法是WHERE price * 0.8 80乘法和大于号各司其职。需求二列出“库存不足100本且已销售超过500本”的书。这里有“且”的逻辑关系但判断库存不足本质是用比较运算符判断销量超过也是用“且”则交给AND逻辑运算符。比较运算符负责两个独立的判断AND负责把两个真/假结果组合起来。需求三把“定价加10元运费后”的结果按从高到低排序展示。这里算术运算出现在ORDER BY子句中甚至可以用别名SELECT book_name, price 10 AS final_price FROM books ORDER BY final_price DESC;可以看到算术运算符既能出现在SELECT输出列中计算结果作为新列也能出现在WHERE筛选条件中还能出现在ORDER BY排序逻辑中。比较运算符则主要出现在WHERE和HAVING中负责筛选。两者分工明确又经常串联协作。3. 环境准备与基础数据初始化3.1 建表与准备一套“能反复折腾”的测试数据动手实操之前我们需要一套稳定的练习环境。MySQL或MariaDB都可以实在不行用SQLite也行但下面的示例我按标准SQL和MySQL风格来写。建议开一个全新的测试库别拿生产数据练手。首先创建数据库和表CREATE DATABASE IF NOT EXISTS bookstore_demo; USE bookstore_demo; CREATE TABLE books ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, category VARCHAR(50), price DECIMAL(10,2), stock INT, sales INT );然后插入一批具有典型特征的数据。我故意让数据包含一些边界情况和特殊值方便后续演示运算符的坑INSERT INTO books (book_name, category, price, stock, sales) VALUES (数据结构与算法, 计算机, 89.00, 120, 800), (数据库系统概论, 计算机, 56.00, 80, 1500), (网络攻防实战, 计算机, 99.50, 45, 320), (西方哲学史, 人文社科, 68.00, 200, 260), (经济学原理, 人文社科, 78.00, 0, 980), (机器学习入门, 计算机, 128.00, 15, 42), (三体全集, 科幻文学, 88.00, 300, 5000), (人类简史, 人文社科, 45.50, 150, NULL), (深入理解计算机系统, 计算机, 139.00, NULL, 600), (小王子, 少儿文学, 15.00, 500, 9999);这里我故意制造了几个特殊场景经济学原理的库存stock是0为的是演示除法和比较运算中“零值”的问题人类简史的销量sales是NULL演示NULL参与运算和比较时“查不到数据”的经典坑深入理解计算机系统的库存是NULL和上面那个形成一对呼应不同价格带、不同销量段的数据都有方便设计各种组合查询3.2 先跑一遍基建确认数据落库插入完成后用一条最简单的查询确认数据没问题SELECT book_id, book_name, price, stock, sales FROM books;我在实际教学中要求学员每条SELECT命令写完必看一眼结果行数和内容。这不光是“验一下有没有成功”更是培养对数据的敏感度。之后所有运算符的判断脑子里都要能“预演”出对应行的计算结果。没这个习惯写复杂查询就成盲人摸象。4. 算术运算符详解与实操演示4.1 加减乘除与取模语法简单细节不简单算术运算符在SQL里的角色跟在Excel里类似无非是加减乘除取模。MySQL里常用的列表如下运算符含义示例结果加法10 313-减法10 - 37*乘法10 * 330/除法10 / 33.3333DIV整数除法10 DIV 33% 或 MOD取模取余10 % 31注意两点。第一SQL里用单个斜杠/表示除法和很多编程语言的整除不太一样它会保留小数部分。第二DIV是整数除法直接舍去小数而取模得到余数。这两兄弟在实际业务里都很有用比如DIV可以算“能装多少整箱”取模可以算“剩下多少散装”。拿我们书店表举个例子计算每本书打折后价格打七折SELECT book_name, price, price * 0.7 AS discounted_price FROM books;执行结果里会多出一列打折价原价和计算结果并列展示。这个操作在SELECT输出层做不影响原表数据。再看一个稍微有业务味道的例子计算每本书的“库存周转次数”可以用销量除以库存SELECT book_name, sales, stock, sales / stock AS turnover FROM books;这句就有意思了。因为有经济学原理这本库存为0的书也有深入理解计算机系统这本库存为NULL的书跑完后你会看到两种情况一种结果是NULL因为NULL参与除法一种直接报错或者显示NULL除数为0时MySQL返回NULL并伴随warning。等一下我先留个悬念咱们到常见问题部分再深挖这个坑。4.2 取模运算的实际应用分组、奇偶和周期性判断取模运算在初学者眼里似乎只在数学题里出现但实际上非常实用。一个经典用法是把数据分成两组比如按照商品编号的奇偶性做抽样SELECT book_name, book_id, book_id % 2 AS parity FROM books WHERE book_id % 2 1;这句会筛选出编号为奇数的书。如果只想取偶数把条件改成 0即可。当年我是在做A/B测试的时候频繁使用这种技巧——把用户ID取模后分成两个实验组不需要额外维护分组标记字段。取模还有一种经典用法是周期判断比如判断某个数字是否为另一个数字的倍数SELECT book_name, sales FROM books WHERE sales % 100 0;这里会把销量为整百的记录筛出来。虽然我们的数据里不一定有但你可以把销售目标设置为“目标完成量是100的整数倍”之类的检查逻辑。学会这个思路以后处理周期任务、轮询分配、表格着色分组都会方便很多。取模运算要特别注意负数行为。在MySQL中-5 % 2的结果是-1而不是1因为结果符号被被除数主导。如果你在处理账户余额之类的数据取模前必须想清楚符号问题必要时先用ABS函数取绝对值。4.3 运算符优先级先算谁后算谁统统听括号的很多人以为SQL里乘除加减的优先级和数学一样就完事了但真到了复杂表达式里还是会混乱。下面这个表达式你能一口说出结果吗SELECT 10 5 * 2 - 8 / 4;按照数学规则先乘除后加减结果是10 10 - 2 18SQL里也完全相同。但问题是当表达式里混着比较运算和逻辑运算时规则就复杂了。完整的优先级顺序大致是括号算术运算符乘除先于加减比较运算符NOTANDOR举个例子。查询“价格大于50且销量大于1000或者价格小于30”的书SELECT book_name, price, sales FROM books WHERE price 50 AND sales 1000 OR price 30;因为AND比OR优先这句实际逻辑是“价格大于50且销量大于1000或者价格小于30”。如果用括号明确写出SELECT book_name, price, sales FROM books WHERE (price 50 AND sales 1000) OR (price 30);效果一样但可读性好很多。我的建议是不管优先级规则背得多熟只要涉及混合条件的WHERE语句一律给核心逻辑加括号。这不是能力问题是协作问题——别人读你的SQL时不应该去心算优先级。提示我在调试SQL时遇到结果不对第一件事就是检查WHERE条件的括号结构。很多“看起来没问题”的查询实际是优先级把逻辑带偏了。5. 比较运算符详解与实操演示5.1 等于、不等于、大于、小于先建立一个“比较结果只有真/假/NULL”的认知比较运算符的语法看起来没啥好学的无非是、!或、、、、。但我观察下来新手最容易忽略的一点是比较运算的结果不只有“真”和“假”还有第三态“NULL”未知。这句话怎么理解假设有个人类简史这本书的sales是NULL执行SELECT book_name, sales FROM books WHERE sales 1000;你会发现这本书既没有被筛出来也没有任何报错。原因在于NULL 1000这个比较的结果既不是TRUE也不是FALSE而是NULL。数据库在WHERE中只保留TRUE的行NULL会被直接丢弃。这个特性太容易踩坑了。很多新手在排查“为什么查不到某条记录”时先怀疑SQL写错其实只是因为某个字段被比较的字段值是NULL。NULL不是一个具体的值它表示“未知”“不存在”“尚未录入”。所有对NULL做常规比较运算的结果都会是NULL。比如查询销量小于等于500的书SELECT book_name, sales FROM books WHERE sales 500;结果不会包含人类简史因为它虽然未知但不满足“小于等于500”的条件判定。数据库的规则是只有明确满足条件的记录才输出NULL状态一律不过滤出来。5.2 常见比较运算符的对照与适用场景运算符含义典型场景等于精确匹配某个分类、某个ID! 或 不等于排除某个分类或状态大于查找价格高于阈值大于等于查找价格不低于阈值小于查找库存低于阈值小于等于查找销量不高于阈值安全等于可处理NULL的相等比较MySQL特有BETWEEN ... AND ...区间包含查找价格在某区间内IN (...)集合包含匹配多个离散值LIKE模糊匹配按模式匹配字符串IS NULL判断为空查找字段值为NULL的记录IS NOT NULL判断非空排除字段值为NULL的记录这里面我特别想点名两个运算符和BETWEEN ... AND ...。是MySQL的安全等于运算符它在比较时把NULL视为一个可比较的值。例如SELECT book_name, sales FROM books WHERE sales NULL;这一句的效果等同于WHERE sales IS NULL可以找出人类简史这一行。但是我不建议在日常查询中用替代IS NULL可读性差只是一方面更重要的是它不是标准SQL的通用写法换到其他数据库可能要重写。BETWEEN ... AND ...是双闭区间包含两端边界值。比如“价格在50到100之间”SELECT book_name, price FROM books WHERE price BETWEEN 50 AND 100;它等价于price 50 AND price 100包含等于两端的情况。这个等价关系很多人记反了以为是开区间于是查询边界值的时候漏数据。实际排查数据不一致问题时我经常遇到这类边界差异一个人在报告里说“用BETWEEN查出来的记录比用和查出来的少”我听了第一反应就是不可能BETWEEN就是包含边界除非他把端点的数据类型给搞拧了比如字符串比较和数值比较混在一起。5.3 字符串比较和日期比较别把“数字字典序”不当回事比较运算符不只能比较数字还能比较字符串和日期。但字符串比较的规则和直觉可能不太一样。在MySQL中字符串比较默认不区分大小写取决于排序规则并且按照“字符的字典序”逐字符比较。比如SELECT book_name FROM books WHERE book_name M;这个查询会把所有书名首个字符在字母表中排在M之后的书找出来。注意这里不是比长度而是比“字典顺序”。还有一个常见的坑字符串和数字混合比较时MySQL会把字符串转换成数字。比如10abc会被转成10abc会被转成0。如果你有一个字段VARCHAR类型存的是“1”“2”“10”这些字符串用比较时得到的结果可能和数值比较不一样。SELECT * FROM temp WHERE varchar_num 9;如果表里varchar_num存的是10可能查不出来因为MySQL在比较时把字符串10转成数字再比。这个转换行为大多数时候符合预期但遇到10abc这种半截字符串就会产生诡异结果。我做过一次数据清洗的时候发现一批文本型编号在排序时出现“10”排在“9”前面就是字符串字典序导致的解决方案是CAST成数字类型再比较。日期比较相对简单只要字段类型是DATE或DATETIME用字符串比较即可SELECT book_name FROM books WHERE DATE(create_time) 2024-01-01;本质上是把日期格式化成统一的字符串格式后比较只要格式一致比较结果和日期先后顺序完全一致。5.4 LIKE模糊匹配和比较运算符联合使用的经典场景LIKE是模式匹配虽然不叫“比较运算符”但在WHERE语句里干的就是比较的活。它和普通比较运算符有本质区别普通比较判断“是否相等”或“大小关系”LIKE判断“是否符合某个模式”。两个通配符必须掌握%匹配任意长度字符包括0个字符_匹配单个字符例如SELECT book_name FROM books WHERE book_name LIKE 数据%;这个查询会把所有以“数据”开头的书名筛出来。再如查找“两个字的书名”SELECT book_name FROM books WHERE book_name LIKE __;两个下划线表示恰好匹配两个字符。这类需求在清洗脏数据时非常常用比如筛出所有异常短的名称。LIKE还有一个搭配NOT LIKE用于排除匹配特定模式的行。查询书名不以“计算机”结尾的书SELECT book_name FROM books WHERE book_name NOT LIKE %计算机;但注意如果某行的book_name为NULLNOT LIKE同样会得到NULL该行不会出现在结果中。这又是NULL的“Third State”问题在不断提醒你它无处不在。6. 综合案例实战从零写出一套完整的单表查询6.1 需求拆解先翻译业务再翻译SQL理论知识看再多都不如动手写一个真实需求来得深刻。假设现在有个实际任务要求从books表里查出“所有价格打九折后不低于60元、且库存少于200本的计算机类图书按折算价从高到低排序输出书名、原价、折算价和当前库存”。第一步拆解业务需求把自然语言转成SQL关键字“价格打九折后”price * 0.9“不低于60元”比较运算 60“库存少于200本”stock 200“计算机类”category 计算机“按折算价从高到低排序”ORDER BY price * 0.9 DESC第二步把这些翻译组合成查询语句SELECT book_name, price, price * 0.9 AS discounted_price, stock FROM books WHERE category 计算机 AND price * 0.9 60 AND stock 200 ORDER BY discounted_price DESC;注意我在这里用了别名discounted_price并且在ORDER BY中直接引用。MySQL允许ORDER BY用SELECT中定义的别名这让排序逻辑更清晰。但是WHERE子句中不能直接引用别名因为在WHERE执行时SELECT列表的别名都还没计算出来。所以在WHERE里要写完整的表达式price * 0.9。这个细节非常容易踩坑我记得刚接触SQL那年经常写完WHERE discounted_price 60然后报错还以为是数据库抽风。实际上SQL的执行顺序是先FROM再WHERE再SELECT最后才是ORDER BY。别名是SELECT阶段才产生的WHERE阶段根本看不到它。6.2 多条件组合与括号的实战演练再看一个稍复杂的案例。需求找出“人文社科类中价格低于70元或者科幻文学类中销量高于1000本”的图书同时只要库存大于0的记录。翻译成SQLSELECT book_name, category, price, stock, sales FROM books WHERE (category 人文社科 AND price 70) OR (category 科幻文学 AND sales 1000) AND stock 0;停一下。我特意写了一个看起来“挺合理”但实际有问题的版本。根据优先级AND比OR高上面这句的真实逻辑是WHERE (category 人文社科 AND price 70) OR (category 科幻文学 AND (sales 1000 AND stock 0))其实并不是这样我上面用改写的版本可能引起误解让我重新来。按照优先级规则AND先结合所以这句的实际解析是WHERE (category 人文社科 AND price 70 AND stock 0) OR (category 科幻文学 AND sales 1000 AND stock 0)看到差别了吗“库存大于0”这个条件被同时加到了两个分支上。如果我原本的意图是“两个分支都要库存大于0”这倒也不算错。但如果我原本的意图是“只要满足前面任一条件就不管库存”那就是错误的。这正是括号如此重要的原因。正确的写法要么是WHERE (category 人文社科 AND price 70 OR category 科幻文学 AND sales 1000) AND stock 0;要么更稳妥地加满括号WHERE ((category 人文社科 AND price 70) OR (category 科幻文学 AND sales 1000)) AND stock 0;我在审查别人的SQL时发现这类优先级错误出现频率极高。尤其是后来补需求往已有SQL里追加条件的时候最容易把新条件放错位置。所以我的铁律是当一个WHERE里有超过两个布尔条件就全部用括号把独立语义分组。6.3 运算符与聚合、排序的联动运算符还能和聚合函数如COUNT、SUM、AVG配合使用在GROUP BY之后做筛选。虽然这个项目聚焦的是单表查询但提前打个基础对理解后续内容很有帮助。举一个例子按分类统计“库存少于200本的图书数量”SELECT category, COUNT(*) AS low_stock_count FROM books WHERE stock 200 GROUP BY category;注意一个关键区别stock 200这个比较运算发生在GROUP BY分组之前所以它是在WHERE里写而不是HAVING。如果想筛选“分组之后每个分类的图书数量大于1”的分组才用HAVING COUNT(*) 1。这里就看出运算符在两个阶段的不同角色了WHERE阶段的比较运算是“先筛行再分组”HAVING阶段的比较运算是“先分组再筛组”。排序方面ORDER BY支持对表达式计算结果排序SELECT book_name, price, stock, price / stock AS avg_price_per_stock FROM books ORDER BY avg_price_per_stock DESC;这个查询按“单本库存对应的价格”来排序。虽然在这里业务意义比较牵强但它展示了“先算术运算生成新值再按新值排序”的完整链路。实际做经营报表时经常用到类似逻辑比如按“利润率”“客单价”“库存周转天数”等衍生指标排序这些指标本身就是算术表达式。7. 常见问题与排查技巧实录7.1 NULL参与比较和运算查不到、不算数、别慌NULL是新手遇到最多、也是最难理解的问题。它在数据库里代表“未知”不是0不是空字符串不是“没有值”而是“我不知道是什么”。我知道一个最经典的现场有个同事排查了一下午为什么系统里某本书的销量为NULL时更新库存的语句总是把所有行都改掉。最后发现他写了这样的代码SELECT book_name FROM books WHERE sales NULL;这个查询永远返回空集因为NULL NULL的比较结果是NULL不是TRUE。要判断是否为NULL必须用IS NULL。再看NULL参与算术运算的情形SELECT book_name, sales * 2 FROM books;对于人类简史这行sales为NULL结果是NULL。NULL和任何数字做加减乘除结果都是NULL。这个特性在设计更新语句时尤其危险。比如UPDATE books SET stock stock - 5 WHERE book_id 9;如果stock本身是NULL那么stock - 5的结果仍然是NULL而不是-5。库存神秘的“扣不动”原因就在这里。排查这种问题不能只看SQL还要看数据本身是否为NULL。7.2 除数为零和浮点精度你以为结果错了其实是机制不同直接用除法的时候如果除数为0MySQL会返回NULL并产生一个warning。这不是崩溃也不一定是错误但有业务含义的设计必须小心。比如计算周转率时有库存为0的书得到的NULL可能会被报表程序解读成“无数据”而不是“周转率为无穷大或不可计算”。不同解读会导致完全不同的业务决策。对策是使用条件判断比如用CASE WHEN或NULLIF函数SELECT book_name, sales / NULLIF(stock, 0) AS turnover FROM books;NULLIF(stock, 0)的意思是如果stock等于0就返回NULL否则返回stock。这样sales除以NULL的结果是NULL避免了除零警告。不过这只解决了“不报错”的问题至于要不要把NULL进一步替换成0要看业务语义。浮点精度是另一个隐形杀手。DECIMAL类型在MySQL里存储精确数值但直接用浮点类型FLOAT/DOUBLE做比较可能遇到类似0.1 0.2 ! 0.3的问题。工程上比较两个浮点数是否相等不建议用而是用“差值绝对值小于某个极小值”的方式。但在数据库字段设计上金额类字段一律用DECIMAL不要用FLOAT这是我在金融项目里被罚过之后长记性的教训。7.3 字符串比较与隐式类型转换WHERE的条件值加不加引号结果差很远WHERE里字段是字符串类型但比较值没加引号会发生隐式类型转换。比如SELECT * FROM books WHERE book_name 123;MySQL会把所有book_name转成数字再比较。如果表里有很多非数字开头的字符串它们转型后都变成0那么book_name 123可能查不到任何东西而book_name 0可能匹配出一堆奇怪的记录。这种问题非常难排查因为从SQL语法上看完全没毛病。反过来数值字段与字符串比较时也是如此SELECT * FROM books WHERE price 89.00;MySQL会把字符串转成数字所以这个查询正常返回。但如果你在WHERE中写price 89它也会匹配到89.00因为转换后数值相等。这类“宽松”行为日常用起来方便但一旦查询性能下降很可能就是因为字段上被加了隐式转换导致索引失效。所以在设计表时类型一定要严格区分查询时比较值的类型也要和字段类型保持一致宁可多写一个CAST也别偷懒。7.4 中文排序与比较的规则中文按照Unicode或拼音排序不同字符集的默认排序规则不同。在MySQL中utf8mb4_general_ci不区分大小写也不严格按照拼音顺序排列utf8mb4_unicode_ci更接近Unicode标准。如果你执行SELECT book_name FROM books ORDER BY book_name;中文记录的顺序可能与你的预期不同这不一定是Bug而是排序规则决定的。需要按拼音排序可以用特定排序规则或在设计阶段就考虑好字符集和排序规则。这个项目里不深究但遇到“为什么我ORDER BY之后顺序这么怪”的问题别怀疑SQL写错先查排序规则和环境变量。7.5 常见问题速查表问题场景可能原因解决方案查询结果缺失某条记录字段值为NULL普通比较失效使用IS NULL或IS NOT NULLWHERE里使用SELECT别名报错执行顺序问题在WHERE中写完整表达式除数为0出现NULL或warning数据中有0值使用NULLIF或CASE WHEN防护字符串比较结果诡异隐式类型转换统一类型避免无引号比较中文排序不符合预期字符集排序规则问题指定排序规则或修改字符集结果多出意料之外的行AND/OR优先级混淆给每个独立逻辑加括号取模负数结果不对符号与被除数一致先取绝对值再做运算或确认业务需求8. 扩展思考运算符能力的进阶之路8.1 从单表到多表比较运算符是JOIN的底层逻辑学会单表运算符之后进阶的第一步是理解JOIN。很多人第一次学JOIN觉得困难其实JOIN条件的本质就是比较运算——两表的关联字段做相等或不等的比较。比如SELECT * FROM orders o JOIN books b ON o.book_id b.book_id;这里的o.book_id b.book_id就是一个跨表的等值比较。如果你在单表中已经养成了“比较运算符结果是TRUE/FALSE/NULL”的认知就会明白为什么JOIN时要选非NULL的关联字段。NULL值和NULL值用等号关联结果是NULL匹配不上。8.2 运算符与索引的关系这也是一个比较隐蔽的坑。WHERE条件中的运算方式直接影响索引是否能被使用。比如WHERE price * 2 200很多数据库无法直接使用price字段上的索引因为索引是基于原始值构建的对表达式计算结果的筛选无法直接走索引。改写为WHERE price 100如果业务逻辑允许优先在查询条件里让字段保持裸状态把运算放到常量一侧。这类微小的写法差异在大表上可能造成几十倍的性能差距。8.3 运算符之外逻辑运算符是不可或缺的黏合剂虽然这个项目叫“算术运算符和比较运算符”但实际查询很少只用单一运算符。逻辑运算符AND、OR、NOT把多个比较表达式串成完整的条件组。我建议在学习时把这三类运算符视为一个整体来理解算术运算符负责“算”比较运算符负责“判”逻辑运算符负责“合”。缺了任何一块单表查询都写不完整。我个人在实际操作中的最后一个建议是准备一个专门的练习库往里面塞一些带有NULL、0值、重复值、边界值的数据然后刻意去写各种运算符组合。踩一遍坑比看十遍文档都管用。尤其要把BETWEEN的边界、IN和的差异、LIKE的转义、NULL的判断这四件事练到形成肌肉记忆后面的查询之路会轻松很多。
1. 项目解读单表查询里最不起眼却最要命的两个运算符先聊点实在的。很多人学SQLSELECT和FROM写完就觉得自己会查数据了结果一到实际需求就卡住什么“查价格打了八折后还大于一百的商品”“找库存低于五十的畅销书”“把订单金额加上运费后排序”这些其实都是单表内就能解决的事但第一步就栽在运算符上。这个项目“单表数据记录查询”把算术运算符和比较运算符单独拎出来讲我之前带新人时也喜欢这么设计教学顺序。原因很简单单表查询是理解数据库查询逻辑的起点而运算符是查询条件里最核心的砖块。你不用先懂多表、不懂索引只要把一张表里的算术计算、大小比较搞明白后面学JOIN、子查询、聚合函数都会顺畅得多。反过来如果运算符这关没过后面写出的SQL基本都是碰运气——看着结果对了换一批数据就崩。这个内容适合谁刚接触数据库的学生、准备面试但基础不牢的开发者、还有那些常年只写SELECT * 但想真正掌握条件查询的普通业务人员。说白了它是把“能跑”变成“跑得对”的一道分水岭。我在这篇文章里会把两个运算符的底层逻辑、执行顺序、边界情况、常见坑全部拆开讲并且配一个完整的模拟项目来实际操作一遍。看完之后你再回去写带WHERE条件的查询会明显感觉心里有底。2. 核心概念与整体设计思路2.1 为什么运算符是查询条件的“判断中枢”先建立一个整体认知。SQL查询的本质是“从表中选择满足条件的行”。而“满足条件”这个判断动作就是靠运算符完成的。单表查询的完整结构是SELECT 输出列 FROM 表名 WHERE 行筛选条件 ORDER BY 排序条件 GROUP BY 分组条件 HAVING 组筛选条件大多数人以为WHERE只是“写上字段、写个等号、写个值”但实际上WHERE后面紧跟的是一组逻辑表达式这些表达式由数据列、运算符、常量值共同构成。数据库引擎会逐行读取表中的数据对每一行分别计算这个表达式的结果看它为真还是为假。这个逐行扫描判断的过程就是查询的执行模型。算术运算符负责“计算出一个数值”比较运算符负责“判断两个值的大小或是否相等”。两者经常配合出现比如“计算折扣价后再判断是否落在某个价格区间”。单独学其中一个都不难但组合起来使用才是真实业务场景。我见过很多初学者写出这样的代码SELECT * FROM products WHERE discount_price 100;如果表中只有原价字段没有折扣价字段这个查询直接报错。正确做法是SELECT * FROM products WHERE price * 0.8 100;这里就同时用到了算术运算符乘和比较运算符大于。所以学运算符不只是认识符号更要理解它们可以嵌在表达式里嵌在WHERE条件的各个角落。2.2 运算符在单表查询中的“分工协作”我们把这套运算符放进实际查询任务里来看它们的协作方式。拿某书店的图书库存表为例表结构大概长这样book_id图书编号book_name书名category分类price定价stock当前库存sales已销售量现在要完成几个典型需求需求一列出“价格打八折后仍大于80元”的书。这个需求要求先对price做算术运算再与80做比较。SQL写法是WHERE price * 0.8 80乘法和大于号各司其职。需求二列出“库存不足100本且已销售超过500本”的书。这里有“且”的逻辑关系但判断库存不足本质是用比较运算符判断销量超过也是用“且”则交给AND逻辑运算符。比较运算符负责两个独立的判断AND负责把两个真/假结果组合起来。需求三把“定价加10元运费后”的结果按从高到低排序展示。这里算术运算出现在ORDER BY子句中甚至可以用别名SELECT book_name, price 10 AS final_price FROM books ORDER BY final_price DESC;可以看到算术运算符既能出现在SELECT输出列中计算结果作为新列也能出现在WHERE筛选条件中还能出现在ORDER BY排序逻辑中。比较运算符则主要出现在WHERE和HAVING中负责筛选。两者分工明确又经常串联协作。3. 环境准备与基础数据初始化3.1 建表与准备一套“能反复折腾”的测试数据动手实操之前我们需要一套稳定的练习环境。MySQL或MariaDB都可以实在不行用SQLite也行但下面的示例我按标准SQL和MySQL风格来写。建议开一个全新的测试库别拿生产数据练手。首先创建数据库和表CREATE DATABASE IF NOT EXISTS bookstore_demo; USE bookstore_demo; CREATE TABLE books ( book_id INT PRIMARY KEY AUTO_INCREMENT, book_name VARCHAR(100) NOT NULL, category VARCHAR(50), price DECIMAL(10,2), stock INT, sales INT );然后插入一批具有典型特征的数据。我故意让数据包含一些边界情况和特殊值方便后续演示运算符的坑INSERT INTO books (book_name, category, price, stock, sales) VALUES (数据结构与算法, 计算机, 89.00, 120, 800), (数据库系统概论, 计算机, 56.00, 80, 1500), (网络攻防实战, 计算机, 99.50, 45, 320), (西方哲学史, 人文社科, 68.00, 200, 260), (经济学原理, 人文社科, 78.00, 0, 980), (机器学习入门, 计算机, 128.00, 15, 42), (三体全集, 科幻文学, 88.00, 300, 5000), (人类简史, 人文社科, 45.50, 150, NULL), (深入理解计算机系统, 计算机, 139.00, NULL, 600), (小王子, 少儿文学, 15.00, 500, 9999);这里我故意制造了几个特殊场景经济学原理的库存stock是0为的是演示除法和比较运算中“零值”的问题人类简史的销量sales是NULL演示NULL参与运算和比较时“查不到数据”的经典坑深入理解计算机系统的库存是NULL和上面那个形成一对呼应不同价格带、不同销量段的数据都有方便设计各种组合查询3.2 先跑一遍基建确认数据落库插入完成后用一条最简单的查询确认数据没问题SELECT book_id, book_name, price, stock, sales FROM books;我在实际教学中要求学员每条SELECT命令写完必看一眼结果行数和内容。这不光是“验一下有没有成功”更是培养对数据的敏感度。之后所有运算符的判断脑子里都要能“预演”出对应行的计算结果。没这个习惯写复杂查询就成盲人摸象。4. 算术运算符详解与实操演示4.1 加减乘除与取模语法简单细节不简单算术运算符在SQL里的角色跟在Excel里类似无非是加减乘除取模。MySQL里常用的列表如下运算符含义示例结果加法10 313-减法10 - 37*乘法10 * 330/除法10 / 33.3333DIV整数除法10 DIV 33% 或 MOD取模取余10 % 31注意两点。第一SQL里用单个斜杠/表示除法和很多编程语言的整除不太一样它会保留小数部分。第二DIV是整数除法直接舍去小数而取模得到余数。这两兄弟在实际业务里都很有用比如DIV可以算“能装多少整箱”取模可以算“剩下多少散装”。拿我们书店表举个例子计算每本书打折后价格打七折SELECT book_name, price, price * 0.7 AS discounted_price FROM books;执行结果里会多出一列打折价原价和计算结果并列展示。这个操作在SELECT输出层做不影响原表数据。再看一个稍微有业务味道的例子计算每本书的“库存周转次数”可以用销量除以库存SELECT book_name, sales, stock, sales / stock AS turnover FROM books;这句就有意思了。因为有经济学原理这本库存为0的书也有深入理解计算机系统这本库存为NULL的书跑完后你会看到两种情况一种结果是NULL因为NULL参与除法一种直接报错或者显示NULL除数为0时MySQL返回NULL并伴随warning。等一下我先留个悬念咱们到常见问题部分再深挖这个坑。4.2 取模运算的实际应用分组、奇偶和周期性判断取模运算在初学者眼里似乎只在数学题里出现但实际上非常实用。一个经典用法是把数据分成两组比如按照商品编号的奇偶性做抽样SELECT book_name, book_id, book_id % 2 AS parity FROM books WHERE book_id % 2 1;这句会筛选出编号为奇数的书。如果只想取偶数把条件改成 0即可。当年我是在做A/B测试的时候频繁使用这种技巧——把用户ID取模后分成两个实验组不需要额外维护分组标记字段。取模还有一种经典用法是周期判断比如判断某个数字是否为另一个数字的倍数SELECT book_name, sales FROM books WHERE sales % 100 0;这里会把销量为整百的记录筛出来。虽然我们的数据里不一定有但你可以把销售目标设置为“目标完成量是100的整数倍”之类的检查逻辑。学会这个思路以后处理周期任务、轮询分配、表格着色分组都会方便很多。取模运算要特别注意负数行为。在MySQL中-5 % 2的结果是-1而不是1因为结果符号被被除数主导。如果你在处理账户余额之类的数据取模前必须想清楚符号问题必要时先用ABS函数取绝对值。4.3 运算符优先级先算谁后算谁统统听括号的很多人以为SQL里乘除加减的优先级和数学一样就完事了但真到了复杂表达式里还是会混乱。下面这个表达式你能一口说出结果吗SELECT 10 5 * 2 - 8 / 4;按照数学规则先乘除后加减结果是10 10 - 2 18SQL里也完全相同。但问题是当表达式里混着比较运算和逻辑运算时规则就复杂了。完整的优先级顺序大致是括号算术运算符乘除先于加减比较运算符NOTANDOR举个例子。查询“价格大于50且销量大于1000或者价格小于30”的书SELECT book_name, price, sales FROM books WHERE price 50 AND sales 1000 OR price 30;因为AND比OR优先这句实际逻辑是“价格大于50且销量大于1000或者价格小于30”。如果用括号明确写出SELECT book_name, price, sales FROM books WHERE (price 50 AND sales 1000) OR (price 30);效果一样但可读性好很多。我的建议是不管优先级规则背得多熟只要涉及混合条件的WHERE语句一律给核心逻辑加括号。这不是能力问题是协作问题——别人读你的SQL时不应该去心算优先级。提示我在调试SQL时遇到结果不对第一件事就是检查WHERE条件的括号结构。很多“看起来没问题”的查询实际是优先级把逻辑带偏了。5. 比较运算符详解与实操演示5.1 等于、不等于、大于、小于先建立一个“比较结果只有真/假/NULL”的认知比较运算符的语法看起来没啥好学的无非是、!或、、、、。但我观察下来新手最容易忽略的一点是比较运算的结果不只有“真”和“假”还有第三态“NULL”未知。这句话怎么理解假设有个人类简史这本书的sales是NULL执行SELECT book_name, sales FROM books WHERE sales 1000;你会发现这本书既没有被筛出来也没有任何报错。原因在于NULL 1000这个比较的结果既不是TRUE也不是FALSE而是NULL。数据库在WHERE中只保留TRUE的行NULL会被直接丢弃。这个特性太容易踩坑了。很多新手在排查“为什么查不到某条记录”时先怀疑SQL写错其实只是因为某个字段被比较的字段值是NULL。NULL不是一个具体的值它表示“未知”“不存在”“尚未录入”。所有对NULL做常规比较运算的结果都会是NULL。比如查询销量小于等于500的书SELECT book_name, sales FROM books WHERE sales 500;结果不会包含人类简史因为它虽然未知但不满足“小于等于500”的条件判定。数据库的规则是只有明确满足条件的记录才输出NULL状态一律不过滤出来。5.2 常见比较运算符的对照与适用场景运算符含义典型场景等于精确匹配某个分类、某个ID! 或 不等于排除某个分类或状态大于查找价格高于阈值大于等于查找价格不低于阈值小于查找库存低于阈值小于等于查找销量不高于阈值安全等于可处理NULL的相等比较MySQL特有BETWEEN ... AND ...区间包含查找价格在某区间内IN (...)集合包含匹配多个离散值LIKE模糊匹配按模式匹配字符串IS NULL判断为空查找字段值为NULL的记录IS NOT NULL判断非空排除字段值为NULL的记录这里面我特别想点名两个运算符和BETWEEN ... AND ...。是MySQL的安全等于运算符它在比较时把NULL视为一个可比较的值。例如SELECT book_name, sales FROM books WHERE sales NULL;这一句的效果等同于WHERE sales IS NULL可以找出人类简史这一行。但是我不建议在日常查询中用替代IS NULL可读性差只是一方面更重要的是它不是标准SQL的通用写法换到其他数据库可能要重写。BETWEEN ... AND ...是双闭区间包含两端边界值。比如“价格在50到100之间”SELECT book_name, price FROM books WHERE price BETWEEN 50 AND 100;它等价于price 50 AND price 100包含等于两端的情况。这个等价关系很多人记反了以为是开区间于是查询边界值的时候漏数据。实际排查数据不一致问题时我经常遇到这类边界差异一个人在报告里说“用BETWEEN查出来的记录比用和查出来的少”我听了第一反应就是不可能BETWEEN就是包含边界除非他把端点的数据类型给搞拧了比如字符串比较和数值比较混在一起。5.3 字符串比较和日期比较别把“数字字典序”不当回事比较运算符不只能比较数字还能比较字符串和日期。但字符串比较的规则和直觉可能不太一样。在MySQL中字符串比较默认不区分大小写取决于排序规则并且按照“字符的字典序”逐字符比较。比如SELECT book_name FROM books WHERE book_name M;这个查询会把所有书名首个字符在字母表中排在M之后的书找出来。注意这里不是比长度而是比“字典顺序”。还有一个常见的坑字符串和数字混合比较时MySQL会把字符串转换成数字。比如10abc会被转成10abc会被转成0。如果你有一个字段VARCHAR类型存的是“1”“2”“10”这些字符串用比较时得到的结果可能和数值比较不一样。SELECT * FROM temp WHERE varchar_num 9;如果表里varchar_num存的是10可能查不出来因为MySQL在比较时把字符串10转成数字再比。这个转换行为大多数时候符合预期但遇到10abc这种半截字符串就会产生诡异结果。我做过一次数据清洗的时候发现一批文本型编号在排序时出现“10”排在“9”前面就是字符串字典序导致的解决方案是CAST成数字类型再比较。日期比较相对简单只要字段类型是DATE或DATETIME用字符串比较即可SELECT book_name FROM books WHERE DATE(create_time) 2024-01-01;本质上是把日期格式化成统一的字符串格式后比较只要格式一致比较结果和日期先后顺序完全一致。5.4 LIKE模糊匹配和比较运算符联合使用的经典场景LIKE是模式匹配虽然不叫“比较运算符”但在WHERE语句里干的就是比较的活。它和普通比较运算符有本质区别普通比较判断“是否相等”或“大小关系”LIKE判断“是否符合某个模式”。两个通配符必须掌握%匹配任意长度字符包括0个字符_匹配单个字符例如SELECT book_name FROM books WHERE book_name LIKE 数据%;这个查询会把所有以“数据”开头的书名筛出来。再如查找“两个字的书名”SELECT book_name FROM books WHERE book_name LIKE __;两个下划线表示恰好匹配两个字符。这类需求在清洗脏数据时非常常用比如筛出所有异常短的名称。LIKE还有一个搭配NOT LIKE用于排除匹配特定模式的行。查询书名不以“计算机”结尾的书SELECT book_name FROM books WHERE book_name NOT LIKE %计算机;但注意如果某行的book_name为NULLNOT LIKE同样会得到NULL该行不会出现在结果中。这又是NULL的“Third State”问题在不断提醒你它无处不在。6. 综合案例实战从零写出一套完整的单表查询6.1 需求拆解先翻译业务再翻译SQL理论知识看再多都不如动手写一个真实需求来得深刻。假设现在有个实际任务要求从books表里查出“所有价格打九折后不低于60元、且库存少于200本的计算机类图书按折算价从高到低排序输出书名、原价、折算价和当前库存”。第一步拆解业务需求把自然语言转成SQL关键字“价格打九折后”price * 0.9“不低于60元”比较运算 60“库存少于200本”stock 200“计算机类”category 计算机“按折算价从高到低排序”ORDER BY price * 0.9 DESC第二步把这些翻译组合成查询语句SELECT book_name, price, price * 0.9 AS discounted_price, stock FROM books WHERE category 计算机 AND price * 0.9 60 AND stock 200 ORDER BY discounted_price DESC;注意我在这里用了别名discounted_price并且在ORDER BY中直接引用。MySQL允许ORDER BY用SELECT中定义的别名这让排序逻辑更清晰。但是WHERE子句中不能直接引用别名因为在WHERE执行时SELECT列表的别名都还没计算出来。所以在WHERE里要写完整的表达式price * 0.9。这个细节非常容易踩坑我记得刚接触SQL那年经常写完WHERE discounted_price 60然后报错还以为是数据库抽风。实际上SQL的执行顺序是先FROM再WHERE再SELECT最后才是ORDER BY。别名是SELECT阶段才产生的WHERE阶段根本看不到它。6.2 多条件组合与括号的实战演练再看一个稍复杂的案例。需求找出“人文社科类中价格低于70元或者科幻文学类中销量高于1000本”的图书同时只要库存大于0的记录。翻译成SQLSELECT book_name, category, price, stock, sales FROM books WHERE (category 人文社科 AND price 70) OR (category 科幻文学 AND sales 1000) AND stock 0;停一下。我特意写了一个看起来“挺合理”但实际有问题的版本。根据优先级AND比OR高上面这句的真实逻辑是WHERE (category 人文社科 AND price 70) OR (category 科幻文学 AND (sales 1000 AND stock 0))其实并不是这样我上面用改写的版本可能引起误解让我重新来。按照优先级规则AND先结合所以这句的实际解析是WHERE (category 人文社科 AND price 70 AND stock 0) OR (category 科幻文学 AND sales 1000 AND stock 0)看到差别了吗“库存大于0”这个条件被同时加到了两个分支上。如果我原本的意图是“两个分支都要库存大于0”这倒也不算错。但如果我原本的意图是“只要满足前面任一条件就不管库存”那就是错误的。这正是括号如此重要的原因。正确的写法要么是WHERE (category 人文社科 AND price 70 OR category 科幻文学 AND sales 1000) AND stock 0;要么更稳妥地加满括号WHERE ((category 人文社科 AND price 70) OR (category 科幻文学 AND sales 1000)) AND stock 0;我在审查别人的SQL时发现这类优先级错误出现频率极高。尤其是后来补需求往已有SQL里追加条件的时候最容易把新条件放错位置。所以我的铁律是当一个WHERE里有超过两个布尔条件就全部用括号把独立语义分组。6.3 运算符与聚合、排序的联动运算符还能和聚合函数如COUNT、SUM、AVG配合使用在GROUP BY之后做筛选。虽然这个项目聚焦的是单表查询但提前打个基础对理解后续内容很有帮助。举一个例子按分类统计“库存少于200本的图书数量”SELECT category, COUNT(*) AS low_stock_count FROM books WHERE stock 200 GROUP BY category;注意一个关键区别stock 200这个比较运算发生在GROUP BY分组之前所以它是在WHERE里写而不是HAVING。如果想筛选“分组之后每个分类的图书数量大于1”的分组才用HAVING COUNT(*) 1。这里就看出运算符在两个阶段的不同角色了WHERE阶段的比较运算是“先筛行再分组”HAVING阶段的比较运算是“先分组再筛组”。排序方面ORDER BY支持对表达式计算结果排序SELECT book_name, price, stock, price / stock AS avg_price_per_stock FROM books ORDER BY avg_price_per_stock DESC;这个查询按“单本库存对应的价格”来排序。虽然在这里业务意义比较牵强但它展示了“先算术运算生成新值再按新值排序”的完整链路。实际做经营报表时经常用到类似逻辑比如按“利润率”“客单价”“库存周转天数”等衍生指标排序这些指标本身就是算术表达式。7. 常见问题与排查技巧实录7.1 NULL参与比较和运算查不到、不算数、别慌NULL是新手遇到最多、也是最难理解的问题。它在数据库里代表“未知”不是0不是空字符串不是“没有值”而是“我不知道是什么”。我知道一个最经典的现场有个同事排查了一下午为什么系统里某本书的销量为NULL时更新库存的语句总是把所有行都改掉。最后发现他写了这样的代码SELECT book_name FROM books WHERE sales NULL;这个查询永远返回空集因为NULL NULL的比较结果是NULL不是TRUE。要判断是否为NULL必须用IS NULL。再看NULL参与算术运算的情形SELECT book_name, sales * 2 FROM books;对于人类简史这行sales为NULL结果是NULL。NULL和任何数字做加减乘除结果都是NULL。这个特性在设计更新语句时尤其危险。比如UPDATE books SET stock stock - 5 WHERE book_id 9;如果stock本身是NULL那么stock - 5的结果仍然是NULL而不是-5。库存神秘的“扣不动”原因就在这里。排查这种问题不能只看SQL还要看数据本身是否为NULL。7.2 除数为零和浮点精度你以为结果错了其实是机制不同直接用除法的时候如果除数为0MySQL会返回NULL并产生一个warning。这不是崩溃也不一定是错误但有业务含义的设计必须小心。比如计算周转率时有库存为0的书得到的NULL可能会被报表程序解读成“无数据”而不是“周转率为无穷大或不可计算”。不同解读会导致完全不同的业务决策。对策是使用条件判断比如用CASE WHEN或NULLIF函数SELECT book_name, sales / NULLIF(stock, 0) AS turnover FROM books;NULLIF(stock, 0)的意思是如果stock等于0就返回NULL否则返回stock。这样sales除以NULL的结果是NULL避免了除零警告。不过这只解决了“不报错”的问题至于要不要把NULL进一步替换成0要看业务语义。浮点精度是另一个隐形杀手。DECIMAL类型在MySQL里存储精确数值但直接用浮点类型FLOAT/DOUBLE做比较可能遇到类似0.1 0.2 ! 0.3的问题。工程上比较两个浮点数是否相等不建议用而是用“差值绝对值小于某个极小值”的方式。但在数据库字段设计上金额类字段一律用DECIMAL不要用FLOAT这是我在金融项目里被罚过之后长记性的教训。7.3 字符串比较与隐式类型转换WHERE的条件值加不加引号结果差很远WHERE里字段是字符串类型但比较值没加引号会发生隐式类型转换。比如SELECT * FROM books WHERE book_name 123;MySQL会把所有book_name转成数字再比较。如果表里有很多非数字开头的字符串它们转型后都变成0那么book_name 123可能查不到任何东西而book_name 0可能匹配出一堆奇怪的记录。这种问题非常难排查因为从SQL语法上看完全没毛病。反过来数值字段与字符串比较时也是如此SELECT * FROM books WHERE price 89.00;MySQL会把字符串转成数字所以这个查询正常返回。但如果你在WHERE中写price 89它也会匹配到89.00因为转换后数值相等。这类“宽松”行为日常用起来方便但一旦查询性能下降很可能就是因为字段上被加了隐式转换导致索引失效。所以在设计表时类型一定要严格区分查询时比较值的类型也要和字段类型保持一致宁可多写一个CAST也别偷懒。7.4 中文排序与比较的规则中文按照Unicode或拼音排序不同字符集的默认排序规则不同。在MySQL中utf8mb4_general_ci不区分大小写也不严格按照拼音顺序排列utf8mb4_unicode_ci更接近Unicode标准。如果你执行SELECT book_name FROM books ORDER BY book_name;中文记录的顺序可能与你的预期不同这不一定是Bug而是排序规则决定的。需要按拼音排序可以用特定排序规则或在设计阶段就考虑好字符集和排序规则。这个项目里不深究但遇到“为什么我ORDER BY之后顺序这么怪”的问题别怀疑SQL写错先查排序规则和环境变量。7.5 常见问题速查表问题场景可能原因解决方案查询结果缺失某条记录字段值为NULL普通比较失效使用IS NULL或IS NOT NULLWHERE里使用SELECT别名报错执行顺序问题在WHERE中写完整表达式除数为0出现NULL或warning数据中有0值使用NULLIF或CASE WHEN防护字符串比较结果诡异隐式类型转换统一类型避免无引号比较中文排序不符合预期字符集排序规则问题指定排序规则或修改字符集结果多出意料之外的行AND/OR优先级混淆给每个独立逻辑加括号取模负数结果不对符号与被除数一致先取绝对值再做运算或确认业务需求8. 扩展思考运算符能力的进阶之路8.1 从单表到多表比较运算符是JOIN的底层逻辑学会单表运算符之后进阶的第一步是理解JOIN。很多人第一次学JOIN觉得困难其实JOIN条件的本质就是比较运算——两表的关联字段做相等或不等的比较。比如SELECT * FROM orders o JOIN books b ON o.book_id b.book_id;这里的o.book_id b.book_id就是一个跨表的等值比较。如果你在单表中已经养成了“比较运算符结果是TRUE/FALSE/NULL”的认知就会明白为什么JOIN时要选非NULL的关联字段。NULL值和NULL值用等号关联结果是NULL匹配不上。8.2 运算符与索引的关系这也是一个比较隐蔽的坑。WHERE条件中的运算方式直接影响索引是否能被使用。比如WHERE price * 2 200很多数据库无法直接使用price字段上的索引因为索引是基于原始值构建的对表达式计算结果的筛选无法直接走索引。改写为WHERE price 100如果业务逻辑允许优先在查询条件里让字段保持裸状态把运算放到常量一侧。这类微小的写法差异在大表上可能造成几十倍的性能差距。8.3 运算符之外逻辑运算符是不可或缺的黏合剂虽然这个项目叫“算术运算符和比较运算符”但实际查询很少只用单一运算符。逻辑运算符AND、OR、NOT把多个比较表达式串成完整的条件组。我建议在学习时把这三类运算符视为一个整体来理解算术运算符负责“算”比较运算符负责“判”逻辑运算符负责“合”。缺了任何一块单表查询都写不完整。我个人在实际操作中的最后一个建议是准备一个专门的练习库往里面塞一些带有NULL、0值、重复值、边界值的数据然后刻意去写各种运算符组合。踩一遍坑比看十遍文档都管用。尤其要把BETWEEN的边界、IN和的差异、LIKE的转义、NULL的判断这四件事练到形成肌肉记忆后面的查询之路会轻松很多。
