关于Query Mapping

在 SQL 优化领域，Query Mapping（查询映射）是一种将复杂查询拆解为原子操作的技术。通过定义原始 SQL 与目标 SQL 的映射关系，它能在不修改应用代码的前提下，实现低效语句到高效语句的 “无感替换”。

TEXT级别

SEMANTICS级别

KingbaseES的Query Mapping：解决 Oracle 用户痛点的 “救命稻草”

Oracle经典性能陷阱：类型不匹配引发的 “慢启动灾难”

Oracle在应用启动时需要读取用户权限相关信息，简化的SQL如下：

select user_privilege from xxx where ID=$1

这是一条很简单的SQL，似乎并没有什么性能问题。但恰恰是这样一个简单的SQL，给用户造成非常大的麻烦。

用户ID由一串数字构成，设计之初，考虑后续可能存在字符类型的数据，所以将ID定义为字符类型数据。应用开发人员在看见数据全为数字类型后，想当然便认为类型应该是数字型，于是将应用变量类型定义为数字类型。这就导致了一个严重的问题“表结构类型的定义与应用变量类型定义不一致”，使得应用无法使用到相关索引，访问效率低下。

在系统系统上线初期数据量不大且用户不多的情况下，用户感知尚且不大。但随着数据量增长，应用每次启动所需时间变得越来越长，系统已慢到无法忍受的地步。

然而此时项目已验收，开发商已离场，应用早已无人维护。怎么办？

可这真的是个难题！

翻遍了数据库的所有功能，只给出了两条不切实际的建议：

方法一：修改应用。这是最好的方法，但显然用户没这个能力。此方法行不通。

方法二：修改表结构定义。可相关联的表的定义要改？有多少本没问题的应用，因为修改定义引发问题？风险太大，不可行。

有人问了，通过HINT强制使用索引是否可行？

要知道，HINT是提示优化器，前提是要能用索引，而这里实际根本用不到索引。因此，厂家提供的SQL Profile 优化工具在这是没用了。

没辙了……

在这种情况下，如果能有KingbaseES Query Mapping 功能，这问题不就迎刃而解了吗？

KingbaseES Query Mapping一键拯救

Query Mapping是KingbaseES提供的性能优化工具，用户可以在不修改应用逻辑的情况下，达到快速解决性能问题的目的。通过语句映射，实现将用户的原始语句根据需要转换成用户想要的语句。

该工具使用简单，且通过内置的系统表记录映射信息，访问非常高效。

具体到实例，只需运行如下命令：

-- 创建映射规则：将原SQL的ID参数转为字符型
select create_query_rule(
  'qm01', -- 规则名称
  'select user_privilege from xxx where ID=$1', -- 原始SQL
  'select user_privilege from xxx where ID=$1::text', -- 目标SQL（添加类型转换）
  true, -- 启用规则
  'text' -- 映射类型（TEXT级别语义转换）
);

通过创建SQL映射，优化器在解析SQL时，如遇到匹配的SQL，将自动对SQL进行转换，有效地避免了对于SQL的修改，整个应用的访问效率得到了非常大的提升。

原来必须通过修改代码的应用，如今仅需通过简单的数据库操作就可以解决。

当然，除了上述的SQL转换的例子，Query Mapping功能还可以广泛应用于其他诸多的场景。例如DBA常见的HINT调优，也可通过Query Mapping，实现不修改应用代码即解决性能问题。

比较 Oracle 固化执行计划方案 的差异

由于统计信息不断发生变化，SQL语句的执行计划往往不稳定。

当数据量变化，或者索引增加，DBA通常需要改变SQL语句才能改善应用系统的性能。

Oracle固化执行计划方案虽然可以解决数据库环境发生变化时的性能问题，但当涉及到数据结构时，则变得无能为力。

而金仓数据库KingbaseES Query Mapping 则可使用完全不同的SQL语句去替代原SQL语句，生成崭新的查询结果。既可优化查询语句，也能从不同的表和列获得结果。