数据库查询优化：先跑常用查询，WHERE条件别凭习惯

更换数据库系统后，不必急于钻研复杂的语法细节。日常开发中最先接触的，依然是那些基础查询条件：=、<>、like、in、between、is null、order by、limit、group by。这些语法看似简单，但在编写迁移 SQL 或排查接口数据时，人们常因“觉得差不多”而疏忽大意，最终掉进意想不到的坑里。

本文使用一张小型测试表，集中验证 KingbaseES 中的常见查询条件。环境为已初始化的 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、draft；name 字段特意设置了 MySQL-basic、mysql-limit、MYSQL-LIKE 等大小写不同的值。score 有一行数据为 NULL，remark 有 4 行数据为 NULL。后续所有查询都将基于这批数据进行验证。

这张表并非实际业务模型，而是专门为测试查询条件而设计。例如，category 字段适合验证 in 和 group by 操作，status 可用于不等值查询和分组统计，score 适用于 between、排序和聚合函数，remark 则用于测试 NULL 值的判断逻辑。

终端提示符显示为 app_db=>，表明当前连接数据库是 app_db，且当前用户并非管理员（提示符不是常见的 #）。这些细节平时容易被忽略，但在编写查询实验时非常实用——至少能确认没有误连到安装时的 test 库，也没有继续使用 system 用户执行所有操作。

等值与不等值查询先行确认

最基础的等值查询结果清晰：

 select id, name, category, status, score
from app_schema.t_filter_demo
where category = 'mysql'
order by id;

返回结果为 1、2、3 三行数据，均属于 mysql 分类。这里先确保最基础的 where category = 'mysql' 能够正常执行，后续再叠加更多查询条件。

不等值查询采用了两种写法进行验证：

 where status <> 'online'

以及：

 where status != '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 组合时括号不可省略

组合条件首先测试 and：

 select id, name, category, status, score
from app_schema.t_filter_demo
where category = 'Kingbase'
  and status = 'online'
order by id;

返回 4、5 两行数据。表中 category 存储的是 kingbase，但查询条件中写的是 Kingbase，当前环境依然能够匹配成功。这一现象与前面提到的 --enable-ci 参数有关——大小写不敏感不是凭空假设的，而是本次查询结果中实际验证到的。

接下来加入 or 条件：

 where (category = 'mysql' or category = 'Kingbase')
  and status = 'online'

返回 1、2、4、5 四行数据。这里的括号绝不能省略。没有括号时，阅读 SQL 的人需要在脑海中重新计算 and 和 or 的优先级；而加上括号后，条件分组在语句中一目了然。

从 MySQL 迁移过来的 SQL 中，大量筛选条件都是这种模式：一个主条件，再叠加几个状态、分类、时间范围等条件。KingbaseES 能够正常运行这些基本条件并不稀奇，真正需要养成的好习惯是：把复杂条件写得清晰明确。尤其是当 or 混在一串 and 中时，括号比任何解释都更可靠。

LIKE 的大小写表现需实际测试

在测试 LIKE 时，特意使用了大小写不同的名称。首先排除名称中包含 sql 的数据：

 select id, name, category
from app_schema.t_filter_demo
where name not like '%sql%'
order by id;

返回 4、6、10、11 四行数据。Kingbase-start、KINGBASE-schema、Oracle-mode、oracle-sequence 均未被 %sql% 匹配到。

接着分别执行以下查询：

 where name like 'MYSQL%'

和：

 where name like 'mysql%'

两次查询的结果都是 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 两类数据：

 select id, name, category, status
from app_schema.t_filter_demo
where category in ('mysql', 'Kingbase')
order by category, id;

返回 6 行数据，包括 3 行 kingbase 和 3 行 mysql。同样，由于当前环境大小写不敏感，Kingbase 能够匹配到表中的 kingbase。

使用 not in 进行反向查询，结果剩下 oracle、pgsql、sql 三类，共 6 行数据。

范围条件使用 between 85 and 95 进行测试：

 select id, name, score, price
from app_schema.t_filter_demo
where score between 85 and 95
order by score desc, 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。使用正确的写法进行查询：

 where remark is null

返回 3、6、9、12 四行数据。反向查询：

 where remark is not null

返回 8 行数据。

再故意使用错误的写法测试一次：

 where remark = null

结果返回 0 行。这个结果非常适合用来提醒自己：NULL 不是一个普通值，不能使用 = 进行匹配。要查询空值，请使用 is null；要排除空值，请使用 is not null。

score is null 也单独执行了一次，只返回 9 号数据 SQL-null。后续的聚合统计会用到这个结果，因为 count(*) 和 count(score) 的结果是不相同的。

从 MySQL 迁移到 KingbaseES，NULL 值处理这块反而不需要学习新的知识点，按照 SQL 标准写法来操作即可。真正需要改变的是那些偷懒的习惯：在接口拼接条件时，不要将 = null 拼进去；在动态 SQL 中，也不要将 NULL 当作普通字符串来处理。

remark 和 score 两个字段都包含了 NULL，但效果不同：remark 是文本备注，适合验证空值筛选；score 是数字类型，后续会参与聚合计算。同样是 NULL，到了统计函数中就会影响计数和平均值，这比单纯查询空行更容易在报表中踩坑。

排序与 LIMIT 可直接组合使用

查询分数最高的 5 行数据：

 select id, name, category, score
from app_schema.t_filter_demo
where score is not null
order by score desc, id
limit 5;

返回结果为 4、11、6、1、5，对应分数 95、92、91、90、88。这里先使用 score is not null 排除掉 NULL 值，再按分数降序排列，最后用 id 作为辅助排序字段。

limit 语法此前已单独验证过，这里放在条件查询中一起使用，更贴近日常开发场景。实际接口中很少只写 limit 5，通常是先筛选，再排序，最后限制返回条数。当排序字段只有一个时，如果出现相同分数，分页结果可能不稳定；多加一个唯一字段作为兜底，结果更容易复现。

本次测试数据中前 5 名没有相同分数，id 兜底看起来不太显眼，但仍然建议写上。等数据量增大后，同一个分数出现多行的情况很常见。分页接口缺少一个稳定的排序字段，问题通常不会立刻暴露，而是在翻页时出现重复行或漏行。

聚合函数会自动跳过 NULL 值

首先对全表进行一次基础统计：

 select
  count(*) as total_count,
  count(score) as score_count,
  min(score) as min_score,
  max(score) as max_score,
  a vg(score) as a vg_score
from app_schema.t_filter_demo;

结果中 total_count 为 12，score_count 为 11。相差的那一行，正是 score 为 NULL 的 9 号数据。min(score) 为 70，max(score) 为 95，a vg(score) 为 84.45454545454545。平均值是基于 11 个非 NULL 分数计算的，而不是按 12 行数据硬性相除。

接下来按状态进行分组统计：

 select status, count(*) as row_count
from app_schema.t_filter_demo
group by status
order by status;

返回结果为 draft=2、offline=3、online=7。

这里与 MySQL 中的常见用法差别不大。真正需要重点关注的是 count(*) 和 count(字段) 的区别。前者统计行数，后者只统计该字段非 NULL 的行数。如果在接口中将这两个混用，统计结果会相差一截。

状态统计结果也顺便验证了前面的插入数据：2 行草稿、3 行下线、7 行在线，加起来正好 12 行。在做这种小实验时，分组结果可以当作一次反向验证，避免后续使用一批本身就不对的数据继续测试。

HA VING 是分组后的过滤条件

最后按分类进行统计：

 select category, count(*) as row_count, a vg(score) as a vg_score
from app_schema.t_filter_demo
group by category
order by category;

结果包含 5 个分类：kingbase 3 行，平均分约 91.33；mysql 3 行，平均分约 82.67；oracle 2 行，平均分 88.50；pgsql 1 行，平均分 87；sql 3 行，平均分 71.50。sql 分类中有一行 score 为 NULL，因此平均分只按 70 和 73 计算。

再加上 ha ving 条件：

 ha ving count(*) >= 2

pgsql 被过滤掉，只保留行数大于等于 2 的分类。where 是在分组前过滤明细行，ha ving 是在分组后过滤聚合结果，这个区别在报表 SQL 中非常常见。

这组查询执行完毕后，日常开发中常用的 WHERE 条件基本都有了清晰的结论。等值查询、不等值查询、and/or 组合、like 匹配、in 列表、between 范围、NULL 值判断、排序、限制条数、聚合函数以及 ha ving 过滤，在当前 V009R001C010 环境中均能按预期正常工作。需要特别标记的有三点：当前实例大小写不敏感，因此 LIKE 和 category = 'Kingbase' 的表现不能脱离环境进行复述；NULL 值只能使用 is null / is not null 进行判断；聚合函数处理 NULL 时，需要清楚 count(*) 和 count(字段) 的差异。

ha ving count(*) >= 2 过滤的是分组后的行数，因此 sql 分类虽然有一个分数为 NULL，但仍然被保留下来——因为它有 3 行明细数据。a vg(score) 只按非 NULL 分数计算，行数和平均值各自独立计算，这一点从 sql 分类的 3 行数据、平均分 71.50 可以清晰看出。

把这些基础条件先跑明白，再去看 JOIN、子查询、窗口函数或者备份恢复等高级内容，心里会踏实很多。SQL 迁移最怕的不是语法复杂，而是基础判断没有经过实际测试就想当然地认为“差不多”。