刚换一套数据库先别急着看复杂语法。日常开发里最先撞上的往往还是那些普通条件、、like、in、between、is null、order by、limit、group by。这些东西看起来简单真到迁移 SQL 或排查接口数据时反而最容易因为“应该差不多”而少看一眼。这次用一张很小的测试表把常见查询条件集中跑一遍。环境是已经初始化好的app_db表放在app_schema下。当前实例初始化时启用了--enable-ci所以大小写相关的结果只按当前环境记录不能直接拿去推所有安装模式。先准备一批够用的数据测试表叫app_schema.t_filter_demo。字段没有故意设计得复杂name放名称category放分类status放状态score和price用来做范围、排序和聚合remark专门留给 NULL 判断。数据一共 12 行里面混了几类东西mysql、Kingbase、sql、oracle、pgsql状态有online、offline、draftname里故意放了MySQL-basic、mysql-limit、MYSQL-LIKE这种大小写不同的值。score有一行是 NULLremark有 4 行是 NULL。后面的每个查询都靠这批数据说话。这张表不是业务模型只是为了把查询条件喂饱。比如category适合看in和group bystatus适合看不等值和分组统计score适合看between、排序和聚合函数remark适合看 NULL 的判断方式。终端提示符是app_db说明当前连接库是app_db当前用户不是管理员提示符下常见的#。这类小信息平时容易忽略但写查询实验时很有用至少能先确认没有连到安装时的test库也没有继续用system做所有操作。等值和不等值先确认最普通的等值查询没有悬念selectid,name,category,status,scorefromapp_schema.t_filter_demowherecategorymysqlorderbyid;返回的是 1、2、3 三行正好都是mysql分类。这里先把最基础的where category mysql跑通后面再叠更多条件。不等值用了两种写法wherestatusonline以及wherestatus!online两次返回结果一致都是 3、6、8、9、11 这 5 行也就是offline和draft状态的数据。当前环境下和!都能用。写迁移脚本时如果原来的 MySQL SQL 里用了!至少这个场景下没有直接卡住。不过长期写 SQL仍然更接近标准写法!更像从 MySQL 使用习惯带过来的写法。能不能用是一回事团队里怎么统一又是另一回事。这里还顺手确认了一点status online返回的是所有非online的明确值不会把 NULL 混进来。当前测试表的status字段是not null所以结果很好读。如果业务表里状态字段允许 NULL不等值条件就要重新检查不能想当然把 NULL 当成“不是 online”。AND、OR 最怕括号省掉组合条件先看andselectid,name,category,status,scorefromapp_schema.t_filter_demowherecategoryKingbaseandstatusonlineorderbyid;返回 4、5 两行。表里category存的是kingbase查询里写的是Kingbase当前环境仍然匹配到了。这个现象和前面提到的--enable-ci有关系大小写不敏感不是随口假设出来的是这次查询结果里能看到的。再把or加进来where(categorymysqlorcategoryKingbase)andstatusonline返回 1、2、4、5 四行。这里括号不能省。没有括号时读 SQL 的人要在脑子里重新算and、or的优先级有括号时条件分组直接写在语句里。从 MySQL 迁过来的 SQL大量筛选条件都长这样一个主条件再叠几个状态、分类、时间范围。KingbaseES 能跑这些基本条件不稀奇真正要养成的是把复杂条件写得不含糊。尤其是or混在一串and里时括号比解释更可靠。LIKE 的大小写表现要实测LIKE这里特意用了大小写不一样的名称。先排除名字里包含sql的数据selectid,name,categoryfromapp_schema.t_filter_demowherenamenotlike%sql%orderbyid;返回 4、6、10、11 四行。Kingbase-start、KINGBASE-schema、Oracle-mode、oracle-sequence都没有被%sql%匹配到。接着分别查wherenamelikeMYSQL%和wherenamelikemysql%两次结果都是 1、2、3 三行MySQL-basic、mysql-limit、MYSQL-LIKE。这说明当前实例里LIKE对这批字符比较是大小写不敏感的。这里不要把结论写大。只能说当前环境、当前初始化方式下MYSQL%和mysql%查出来一致。如果换成没有启用大小写不敏感的实例或者换字符集、排序规则应该重新跑一遍。迁移 MySQL 的时候LIKE往往藏在搜索接口里大小写表现最好提前确认。还有一个细节not like %sql%把MySQL-basic、mysql-limit、MYSQL-LIKE、SQL-where、sql-order、SQL-null都排除了。这个结果比只看like mysql%更能暴露大小写影响因为%sql%在字符串中间匹配MySQL里的SQL也被算进去了。IN、NOT IN、BETWEEN 都比较顺IN适合替代一串or。这次查mysql和Kingbase两类selectid,name,category,statusfromapp_schema.t_filter_demowherecategoryin(mysql,Kingbase)orderbycategory,id;返回 6 行包括 3 行kingbase和 3 行mysql。同样因为当前环境大小写不敏感Kingbase能匹配到表里的kingbase。反过来用not in结果就是剩下的oracle、pgsql、sql三类共 6 行。范围条件用了between 85 and 95selectid,name,score,pricefromapp_schema.t_filter_demowherescorebetween85and95orderbyscoredesc,id;返回 7 行包含 95也包含 85。between的边界是包含两端的这一点和 MySQL 里常见理解一致。结果按score desc, id排序后最高分是Kingbase-start的 95最低一行是Oracle-mode的 85。这些条件本身不难容易出问题的是数据里有 NULL 的时候。not in遇到 NULL 子查询时会变得麻烦不过这次先只用固定列表不把子查询混进来。NULL 单独看。order by category, id也帮忙看清了返回顺序。in的结果不是按列表里mysql, Kingbase的顺序回来而是按 SQL 里写的排序字段回来。接口如果对返回顺序有要求就把order by写清楚不要靠插入顺序或者in列表顺序。NULL 不要用等号猜remark字段有 4 行是 NULL。用正确写法查whereremarkisnull返回 3、6、9、12 四行。反过来whereremarkisnotnull返回 8 行。再故意写一次whereremarknull结果是 0 行。这个结果很适合拿来提醒自己NULL 不是一个普通值不能用去匹配。要查空值就写is null要排除空值就写is not null。score is null也单独跑了一次只返回 9 号SQL-null。后面的聚合统计会用到它因为count(*)和count(score)的结果不一样。从 MySQL 切到 KingbaseESNULL 这块反而不用背新东西按 SQL 里的正常写法来就行。真正要改的是一些偷懒习惯接口拼条件时不要把 null拼进去动态 SQL 里也不要把 NULL 当成普通字符串处理。remark和score两个字段都放了 NULL效果不一样remark是文本备注适合验证空值筛选score是数字后面会参与avg。同样是 NULL到了统计函数里就会影响计数和平均值这比单纯查出空行更容易在报表里踩坑。排序和 LIMIT 可以直接组合取分数最高的 5 行selectid,name,category,scorefromapp_schema.t_filter_demowherescoreisnotnullorderbyscoredesc,idlimit5;返回结果是 4、11、6、1、5对应分数 95、92、91、90、88。这里先用score is not null把 NULL 排除掉再按分数倒序排最后加id兜底。limit语法前面已经单独验证过这里放在条件查询里看更接近日常用法。实际接口里很少只写limit 5更多是先筛选再排序再限制条数。排序字段只有一个时如果出现同分分页结果可能不稳定多加一个唯一字段做兜底结果更好复现。这次数据里前 5 名没有同分id兜底看起来不显眼但它仍然应该写上。等数据量上来以后同一个分数出现多行很正常。分页接口少一个稳定排序字段问题通常不会立刻暴露而是在翻页时出现重复行或漏行。聚合函数会跳过 NULL先对全表做一次基础统计selectcount(*)astotal_count,count(score)asscore_count,min(score)asmin_score,max(score)asmax_score,avg(score)asavg_scorefromapp_schema.t_filter_demo;结果里total_count是 12score_count是 11。差的那一行就是score为 NULL 的 9 号数据。min(score)是 70max(score)是 95avg(score)是84.45454545454545。平均值按 11 个非 NULL 分数算不是按 12 行硬除。再按状态分组selectstatus,count(*)asrow_countfromapp_schema.t_filter_demogroupbystatusorderbystatus;返回draft2、offline3、online7。这里和 MySQL 里的常见用法差别不大。真正需要盯住的是count(*)和count(字段)。前者数行后者只数这个字段非 NULL 的行。接口里如果把这两个混用统计结果会差一截。状态统计也顺便校验了前面的插入数据2 行草稿、3 行下线、7 行在线加起来正好 12 行。做这种小实验时分组结果能当作一次反查避免后面拿一批本来就不对的数据继续验证。HAVING 是分组后的过滤最后按分类统计selectcategory,count(*)asrow_count,avg(score)asavg_scorefromapp_schema.t_filter_demogroupbycategoryorderbycategory;结果有 5 类kingbase3 行平均分约 91.33mysql3 行平均分约 82.67oracle2 行平均分 88.50pgsql1 行平均分 87sql3 行平均分 71.50。sql分类里有一行score是 NULL所以平均分只按 70 和 73 算。再加上havingcount(*)2pgsql被过滤掉只剩下行数大于等于 2 的分类。where是分组前过滤明细行having是分组后过滤聚合结果这个区别在报表 SQL 里很常见。这组查询跑完以后日常 WHERE 条件基本有了底。等值、不等值、and/or、like、in、between、NULL 判断、排序、限制条数、聚合和having在当前 V009R001C010 环境里都能按预期工作。真正需要单独标记的有三点当前实例大小写不敏感所以LIKE和category Kingbase的表现不能脱离环境复述NULL 只能用is null/is not null聚合函数处理 NULL 时要看清楚count(*)和count(字段)的差别。having count(*) 2过滤的是分组后的行数所以sql分类虽然有一个分数为 NULL仍然保留下来它有 3 行明细。avg(score)只按非 NULL 分数算行数和平均值各算各的这一点从sql的 3 行、平均分 71.50 能看出来。把这些基础条件先跑明白再去看 JOIN、子查询、窗口函数或者备份恢复心里会踏实很多。SQL 迁移最怕的不是语法多而是基础判断没有实测就默认“差不多”。
