接手一份放了两年多的后台代码翻到条件数组那一行写着price [egt, 100]旁边注释还标了一句“大于等于”。当时提问的人一直在搜“mysql egt”因为他以为这是数据库层面的新写法结果搜出来全是零散的关键字片段越看越糊涂。这个场景其实很典型eq、neq、gt、egt、lt、elt、heq、nheq 这八个词既不是 MySQL 的运算符也不是标准 SQL 里的保留字它们是 ThinkPHP 查询构造器内部的一套运算符别名属于“写 PHP 的时候用落到数据库之前就被翻译掉”的语法糖。搞不清这层关系就会犯两类错误一是跑去数据库客户端里手敲egt试效果二是看到heq这种冷门写法完全不知道它在比什么。这篇就把这八个词从身份、翻译结果、使用姿势、性能影响一直到版本迁移的坑一次讲透适合正在维护老项目、或者刚接触这个框架查询写法的人对照着看。1. egt 不是 MySQL 的语法先把这层误会拆开很多人第一次见到这八个运算符是在一段where条件数组里看见形如[gt, 10]的写法下意识把它当成数据库层的语法。这个误会一旦形成后面所有排查都会跑偏——你会去翻数据库手册去查字符集和比较规则却始终找不到答案因为问题根本不在那一层。1.1 直接在数据库里敲 egt 会得到什么如果你打开任意一个数据库客户端写一句SELECT * FROM goods WHERE price egt 100得到的只会是语法错误。数据库的比较运算符是、、、、、这些符号它不认识egt这个单词。也就是说真正的 SQL 语句里永远不会出现这八个词它们只存在于 PHP 源码里在语句被发往数据库之前就已经被替换掉了。理解这一点非常关键。它意味着两件事第一排查问题时你真正该看的是“框架最终拼出来的 SQL 长什么样”而不是原始的条件数组第二这八个词的行为完全由框架的实现决定不同版本之间可能有差异不能想当然地按 SQL 语义去推断。我见过有人拿着[neq, null]的条件在数据库里手工验证验证结果和页面表现完全对不上最后发现是框架对 null 做了特殊处理两边根本不在一个语境里。排查这类问题的第一动作永远是打印最终 SQL而不是盯着一堆条件数组凭空推理。1.2 框架语法糖与 SQL 的翻译关系所谓语法糖就是在某一层做一次映射把可读性更好的写法翻译成底层能执行的形式。这八个运算符干的就是这件事eq映射成neq映射成gt映射成egt映射成lt映射成elt映射成。框架在解析条件数组时先把这个字符串转成大写再去内部的一张映射表里查查到对应的符号就拼进 SQL。查不到的就当作普通字段名或者直接报错。这种设计在早期是很讨巧的条件数组里写[egt, 100]比写[, 100]语义更明确尤其是当条件是通过配置或者接口动态生成的时候用单词比用符号更不容易在传输过程中出错——符号在 URL 编码、配置文件、模板引擎里都可能被转义或者截断单词则稳得多。这也是为什么即便后来的版本主推符号写法老项目里依然大量残留着这套单词运算符。顺带说一句egt这个名字的来历它是 “equal or greater than” 的缩写语序上把 equal 放在了前面所以看起来有点别扭。同理elt是 “equal or less than”。记住这个拼法逻辑就不会把它和gte、lte这类常见缩写搞混——后者是很多数据库驱动和其他语言里的写法两套体系混着记很容易写错。1.3 八个运算符的身份对照表先把全局关系摆出来后面再逐个抠细节。下表左边是你在 PHP 代码里写的右边是大致会被翻译成的形态中间那列是我给它的通俗解释。运算符翻译形态通俗解释使用频率eq等于极高neq不等于高gt大于高egt大于或等于高lt小于高elt小于或等于高heq带HEX()的等于十六进制形态的等于极低nheq带HEX()的不等于十六进制形态的不等于极低前六个基本是日常写条件的主力后两个属于冷门中的冷门很多写了几年的人都没用过一次。但恰恰是冷门的东西最容易出事——你不知道它翻译成什么就不知道它为什么会返回意料之外的结果。表格里“翻译形态”一列我用了“大致”两个字原因在后面第 2 章会讲不同小版本在字符串拼接和引号处理上有细微差别真正准确的答案只能从你当前这套代码里打印出来。2. 逐个拆解八个运算符生成什么样的 SQL光记住映射表还不够真正决定行为的是拼出来的那一整条语句包括引号、括号、参数绑定的位置。这一章按使用频率从高到低拆把每一类容易翻车的地方都点出来。2.1 eq 与 neqNULL 是绕不开的那道坎eq是最没存在感的[eq, 1]就是字段 1没什么可说的。真正麻烦的是neq也就是不等于。SQL 里的语义有个广为人知的陷阱任何值和 NULL 比较结果都是未知既不等于真也不等于假那一行就会被过滤掉。所以status 1这样的条件会把status为 NULL 的记录一并排除掉很多人的预期是“不等于 1 的都要”实际拿到的是“不等于 1 且不为 NULL 的”。这个坑在业务上经常表现为“数据少了几条”。比如一个列表页按状态筛选运营说有些单子明明不是已完成状态却看不到你去查数据发现那几条的状态字段是空的——不是 0是 NULL。修复方式不是改运算符而是补条件把 NULL 的情况显式带上// 意图状态不等于 1 的全部要 // 实际status 为 NULL 的记录会被丢掉 $where[] [status, neq, 1]; // 修正显式把 NULL 纳入 $where[] [status, neq, 1]; $where[] [status, not null]; // 视版本写法而定或用下面的表达式写法关于eq传 NULL 会生成什么这里要格外小心。有些版本会把[field, eq, null]翻译成field NULL那是一条永远不成立的语句一条记录都查不出来也有些版本会识别出 null 并转成IS NULL。两种行为在不同版本、不同调用方式下都可能出现所以我从不在条件里直接传 null需要判空就老老实实写IS NULL的表达式形式或者用框架提供的判空方法。这条经验是用一次线上事故换来的一个筛选器在参数为空时传了 null页面直接空白日志里那条 SQL 看着毫无问题因为它确实是合法的 SQL只是永远为假。2.2 gt、egt、lt、elt边界值与隐式类型转换这四个放在一起讲因为它们的坑是同一类边界和类型。先看边界。egt和gt的区别就在于等号听起来废话但实际业务里“满 100 减 20”这类规则写成gt 100还是egt 100结果差一个订单运营能跟你争论一下午。我的习惯是涉及金额、数量、时间这类有明确业务规则的阈值条件里一定用注释把边界写清楚比如// 满 100 含 100别指望下一个人包括三个月后的自己能从egt和gt一个字母的差别里读出业务意图。类型转换是更隐蔽的一层。当字段是字符串类型而你传进去的是数字比较规则会按字段的类型来定而不是按你传的值来定。举个具体的字段code是 varchar存了9、10、100这样的编号你写[code, gt, 9]框架拼出来的是code 9数据库按字符串比较10和100确实都大于9因为逐字符比1小于9实际上10是小于9的。等一下这里要说清楚字符串比较是逐字符按排序规则比的10 9成立因为第一位1小于9。所以code 9在字符串字段上10和100反而不会被选中选中的是9之后的那些以a到z开头或者数字大于 9 的单字符值。这个例子说明什么说明当你对字符串字段用数值比较运算符时得到的语义和你想的完全不同。要么把字段类型改成数值型要么在值上也保持字符串语义并用CAST之类的表达式明确转换不要指望数据库替你猜。我在评审代码时有个固定动作看到gt、lt这类条件先确认左边字段的实际类型类型对不上就一定要问清楚业务预期。时间字段也是重灾区。create_time存的是 datetime条件写成[create_time, egt, 2024-01-01]字符串会按日期语义比较多数情况下没问题但如果某条数据存了带时分秒的值2024-01-01 00:00:00是等于还是大于2024-01-01取决于数据库怎么补齐不同版本的处理可能让你在跨年那天的统计报表上少算或多算一批数据。稳妥的做法是把边界值补全到秒2024-01-01 00:00:00和2024-01-01 23:59:59成对出现别让数据库去猜你的意图。2.3 heq 与 nheq被 HEX() 包起来的比较这两个是整套运算符里最需要解释的。它们不是简单地把值原样拿去比而是在比较时引入了十六进制的转换。通俗点说heq不是拿你给的值直接和字段比而是先把值转成十六进制形态再参与比对nheq就是它的反义。为什么会有这种设计因为有些场景下字段里存的确实不是明文而是十六进制串或者二进制形态。比如某些校验码、某些需要逐字节比对的特征值用普通的去比可能因为字符集、大小写、尾部空白之类的原因对不上而用十六进制形态比对就绕开了这些问题。理论上很美好实际上用的人极少原因有两个一是业务里真正需要这种比对的场景不多大部分校验直接用哈希值字符串比对就够了二是它的生成形态对索引不友好容易埋下性能隐患后面第 4 章会细说。用的时候有几个必须确认的点。第一你到底想比的是“字段等于这个值的十六进制表示”还是“字段的十六进制表示等于这个值”这两种写法生成的语句结构不同性能天差地别一个是常量侧做转换一个是字段侧做转换。第二值的格式是什么大小写敏感吗带不带前缀这些细节在不同版本里处理方式可能不一致。第三也是最实际的建议用之前先打印 SQL把heq单独拿出来跑一条看看拼出来的到底是什么再决定要不要用。// 先别急着跑业务逻辑单独验证生成结果 $sql Db::name(verify)-where(code, heq, $value)-fetchSql(true)-find(); // 把 $sql 打出来看清楚HEX() 套在哪一侧引号怎么加的我个人的态度是新项目里能不碰heq就不碰。如果确实需要按十六进制或二进制比对直接在条件里写表达式把转换放在哪一侧、怎么加引号全部自己控制比依赖一个冷门别名的隐式行为清楚得多。老代码里遇到了第一件事不是改是打印 SQL 记录下来确认它现在到底在干什么然后再决定重构方案。3. 写条件的几种姿势与注入防线知道每个运算符翻译成什么只是第一步实际项目里条件很少只有一个通常是七八个条件拼在一起还带 OR、带区间、带模糊匹配。这时候运算符本身没问题组合方式出问题。3.1 一维数组条件为什么默认是 AND最省事的写法是给一个关联数组键是字段名值是条件。这种写法下所有条件默认用 AND 连接这一点大部分人清楚。不清楚的是值的形态值写成标量就是等值匹配等价于eq值写成数组[egt, 100]才会走运算符解析。这两种形态混在一个数组里完全合法框架会逐个判断。麻烦出在需要 OR 的时候。一维数组表达不了 OR必须换成索引数组每个元素是[字段, 运算符, 值]的三元组再配合逻辑标识。这时候如果你不小心把两种写法混用比如一部分条件用关联数组、一部分用索引数组塞进同一个where调用得到的结果可能和你想的完全不同——我见过最典型的是想表达“A 或 B”结果写成了“A 与 B 或 C”因为运算符优先级和括号没处理好实际查询范围被放大了一圈。处理多条件组合我的建议很直接条件超过三个就别用一维数组了全部改成三元组的索引数组逻辑关系一目了然。多花的那点敲键盘时间比起事后排查“为什么这条数据被查出来了”要划算得多。3.2 闭包嵌套与 OR 条件的组织方式需要分组的时候闭包是最好用的工具。比如“状态是已支付并且金额大于 100 或者有优惠券”这种嵌套结构用闭包写出来结构清晰生成的 SQL 也会带正确的括号。Db::name(orders) -where(status, eq, 2) -where(function ($query) { $query-where(amount, gt, 100) -whereOr(coupon_id, gt, 0); }) -select();这里有个细节值得说闭包内部的whereOr和外面的where是两层闭包会被括号包起来所以不会污染外层的 AND 关系。如果没有这层括号SQL 里的 OR 会把前面的status 2也一起吃掉变成“状态是已支付且金额大于 100或者有优惠券”范围完全变了。这类 bug 特别隐蔽因为数据量小的时候看不出来等到数据涨起来页面上多出来的那些不该出现的记录才会引起注意。另一个常被忽略的点是空闭包。如果闭包里的条件是根据参数动态判断的可能一个条件都没加进去这时候生成的可能是空括号或者直接报错视版本而定。稳妥的做法是在闭包外面先判断有没有必要加这层分组参数都为空就整个跳过别让一个空括号进到 SQL 里。3.3 参数绑定不是万能药拼接字符串的组合方式风险框架对值一般会做参数绑定或者转义处理这也是很多人觉得“用了框架就不会有注入”的底气来源。但运算符这套东西有个边界运算符本身是从你写的代码里取的字符串如果这个字符串来自外部输入框架的映射表查不到可能就直接拼接进去了。所以有一条铁律运算符必须是代码里写死的字面量绝不能来自请求参数。我做过一个验证思路很简单把运算符位置改成从参数取然后传一个奇怪的值进去观察生成的 SQL 结构有没有被改变。结果不出所料SQL 结构变了。这说明值的安全处理是一回事结构的安全处理是另一回事前者框架帮你兜住了后者得你自己兜。// 危险运算符来自外部 $op $_GET[op] ?? eq; $where[] [amount, $op, $val]; // 安全运算符写死值走绑定 $where[] [amount, gt, $val];如果业务上真的需要前端传“大于/小于”这类选项正确做法是维护一张白名单把前端传来的字符串映射成固定的运算符映射不到就用默认值绝不让它直接进到条件数组里。4. 性能视角比较运算符对索引的实际影响条件写对了只是及格线写得快才是本事。这一章讲的是同一个业务需求换个运算符写法执行计划可能完全不同。4.1 范围运算符的索引用法边界eq和neq在索引上的表现差别巨大。等值查询是最理想的情况能直接定位到索引里的某一段。范围查询如gt、egt、lt、elt也能用上索引但用完范围条件之后后面跟着的其他条件通常就用不上索引了因为 B 树在范围扫描之后已经失去了精确定位能力。这个特性决定了联合索引的字段顺序等值条件的字段放前面范围条件的字段放后面。举个具体的场景。有一张表联合索引建在“状态 创建时间”上。查询是“状态等于 2创建时间大于某个值”这个索引完全能用上先定位状态段再在段内做时间范围扫描。但如果查询变成“创建时间大于某个值状态等于 2”字段顺序对不上索引能发挥的作用就打折了。这不是运算符的错是索引设计和条件顺序没配合好但表现出来的现象往往是“加了个条件就变慢”很容易被误判成运算符有问题。neq的情况要单独说。不等于这个条件天然是“排除一小部分”剩下的范围太大优化器通常会选择全表扫描而不是走索引因为走索引再回表可能比直接扫一遍还慢。所以如果你的查询主条件是neq别指望索引能救你这时候要考虑的是换个思路能不能反过来枚举把“不等于”变成“等于若干值”或者用其他字段先缩小范围。4.2 neq 与函数包裹字段的两类索引失效第一类前面提了neq在大范围下不走索引这是优化器的正常选择不是故障。第二类是真正需要警惕的字段被函数包裹。回到heq。如果它生成的形态是在字段一侧套函数比如把字段整体包进某种转换里再比较那这个字段上的索引就完全用不上了因为索引里存的是字段的原始值不是转换后的值。数据量小的时候完全无感数据量涨到几十万行一条查询从几十毫秒变成几秒这时候才回头去查往往已经影响线上体验了。判断方法很朴素看生成的 SQL 里函数套在哪一侧。套在常量那一侧大概率还能用索引套在字段那一侧索引基本报废。所以我在用任何不熟悉的写法之前都会先EXPLAIN一下看看执行计划这个动作花不了十秒能省掉后面几个小时。-- 看这一条的执行计划重点看 type 和 key 两列 EXPLAIN SELECT * FROM verify WHERE code HEX(abc123);4.3 用 EXPLAIN 反向验证查询构造器的输出我很推荐一个习惯对于任何稍微复杂的查询尤其是用到了范围条件、函数条件、或者冷门运算符的写完之后打印 SQL把这条 SQL 复制到数据库客户端里跑一遍EXPLAIN。这一步的价值在于它把“我以为框架会生成什么”变成了“数据库实际怎么执行”中间那层猜测被消除了。看EXPLAIN结果时重点盯两个地方。type列如果是ALL说明在做全表扫描数据量一大就危险key列如果是空的说明没用上任何索引。rows列是预估扫描行数和实际表行数一比就知道索引发挥了多大作用。这几列看懂大部分性能问题都能定位到具体是哪一段条件拖的后腿。顺带提一句深分页。用limit做偏移分页页码越大越慢因为要先把前面所有的行都扫一遍再丢弃。这不是运算符的问题但如果你的查询本身条件就重叠加起来会很难看。数据量大的列表页考虑用“记住上一页最后一条的标识从那里继续取”的方式跳过偏移量。5. 版本差异与迁移中的真实坑最后一个话题是版本。这套运算符在不同版本里的支持程度和表现形式是有差异的尤其是从老版本往新版本迁的时候很容易踩到“代码没改行为变了”的情况。5.1 从字符串运算符迁到符号写法的对照较新的版本主推符号写法[, 100]这种。迁移的时候需要注意符号写法对字符串运算符的兼容程度不一定完整尤其是heq、nheq这种冷门的很可能直接不支持或者支持但行为不同。我的建议是在迁移前先做一次全量扫描把这些运算符的使用点全部列出来评估每一个的迁移方案。原写法新写法迁移注意点[eq, 1][, 1]直接替换注意 null 处理差异[neq, 1][, 1]注意 NULL 被排除的语义不变[gt, 1][, 1]直接替换[egt, 1][, 1]直接替换[lt, 1][, 1]直接替换[elt, 1][, 1]直接替换[heq, $v]自定义表达式需先打印原 SQL 确认形态再重写[nheq, $v]自定义表达式同上注意取反逻辑迁移完成之后一定要做一轮对比测试同一批查询参数在老代码和新代码下各跑一遍把两次生成的 SQL 都打印出来逐条比对。别看代码逻辑直接看 SQL 文本差异一目了然。这一步看起来笨但比任何单元测试都直观有效。5.2 一次排查条件没生效但其实生效了说一个虚构但很典型的场景。某后台的订单列表页运营反馈筛选条件“金额大于 100”没生效页面上还是出现了小额订单。查代码条件是[amount, gt, 100]看着没问题。打印 SQL得到的是amount 100也没问题。问题出在别处这个条件被塞进了一个嵌套数组里而那个数组整体被当作一个分组处理外层又有一个whereOr在外面。拼出来的实际语句是status 3 OR (amount 100)运算符优先级导致amount 100这一坨并没有和前面的状态条件形成 AND 关系而是变成了可选的。运营看到的小额订单全都满足status 3条件其实是生效的只是被 OR 吃掉了。这次排查给我的教训是不要孤立地看某一个条件。条件数组是一棵树你得从根开始把整棵树的结构在脑子里画出来或者干脆打印完整 SQL 加括号看层次。只看某一个叶子节点永远找不到问题。后来我养成了一个习惯复杂查询的 SQL 打印出来之后先不看内容先数括号括号层次对不上就说明嵌套结构有问题。5.3 我平时用的几条自检习惯积累下来的几条习惯都是在被打脸之后慢慢形成的分享出来供参考。第一看到不认识的运算符先别猜打印 SQL。这套运算符里有些名字看着像英文缩写实际含义和直觉有偏差猜的成本太高。第二任何涉及 null 的条件单独拉出来验证一遍。null 是最容易让语义跑偏的值不验证就上线风险很高。第三范围条件必看字段类型。字符串字段做数值比较结果是字符串比较这个反直觉的程度足够让人写出错误的业务逻辑。第四冷门运算符用之前查执行计划。heq这类写法对索引的影响不直观EXPLAIN一下十秒钟的事。第五迁移前做全量扫描和 SQL 对比。版本换了同一个写法的行为可能变对比着看最放心。这些都是很朴素的习惯没什么技术含量但确实能挡掉大部分低级错误。真正难的部分从来不是记住八个运算符翻译成什么而是在写的时候能想到“这里可能存在一个我不知道的差异”。抱着这个心态去写查询比背十张映射表都有用。
