关键字: 人大金仓、Query Mapping
老车除了报废没别的方法？
应用系统就像老车，经过十几二十年的使用，积累了大量里程数据，于是英雄迟暮，反应迟钝，时不时就要病休。
但直接报废，推到重来，所需预算甚大，着实下不了决心。于是我们开始思考，如何让这辆老车焕发第二春？
积习难改，索性听之任之？
缓慢地启动
司机已稳坐驾驶室，安全带系好，发动机启动，一切准备就绪。但老车慢热，十分钟过去了，还是不能出发......
工作时间到了，数据库管理员（DBA）纷纷打开应用系统，随即就把它切换到后台，开始其他的工作。因为应用系统在数十年的工作中已累计了海量数据，加之软件用户倍增，使得系统性能直线下降，功能界面启动耗费时间就越来越长。
但是人们似乎已习惯于这样工作模式，不愿改进。
仪表盘的指针总是滞后
今天收到了超速罚单，实在是冤枉！
老司机驾驶认真，时刻注意指针避免超速，但老爷车的仪表盘速度指示滞后，还是被超速摄像头抓拍了。
系统又崩溃了，真是无奈！
DBA精勤工作，然而老系统迟钝，告警信息不够及时，以至于无法在数据库处于崩溃边缘时力挽狂澜。
又在高速抛锚
需要高速行驶的时间越来越长，老车就此罢工。
应用系统虽然升级了服务器资源，但是低效的查询语句，把新资源消耗在冗余的运算中。
增加一个行李架，不得不降速
行李越来越多，需要加装行李架，但是车速就要下降了。
新的业务不断地加入到应用系统，但应用系统原有模式的性能已不能满足新的需求。
车虽老，使用更频繁
出行需求多了，根本没有休息的时间，只能一边运转，一边改善维修。
7*24 的应用系统，使得DBA并没有足够的运维窗口时间。而晚间定时任务的执行时间越来越长，以至执行到了第二天上班时间。
深挖潜能，不断涌现新问题
全表过滤不能满足性能要求
部分查询没有预计到数据表的增大，原本可以全表条件过滤的查询已不满足性能要求，严重影响工作。
数据多源，使用视图代替原表名
业务类型增加，数据来源复杂，DBA不得不使用视图整合多源的数据表，增加了查询的硬解析时间。
数据海量增长，使用分区表
过多分区的分区表带来了超长的执行时间，无法满足频繁执行的查询。
外部数据增加，网络交互量延长查询时间
远程外部表数据突增，并且持续增长，原本性能良好的查询突然变慢。
性能瓶颈，深度排查及定位
运行多年负荷逐渐增加
l 数据量积累
l 用户数增多
l 功能点使用增多
数据库优化手段
优化SQL语句，但：
l 复杂多变的过滤条件，无法创建适合的索引
l 商业软件的SQL语句已经封装，不能修改
l 应用系统已验收，开发团队已经离场
上述原因，使得在数据库中执行的SQL语句无法被改变。
硬件优化与升级
l 升级CPU，增加并行度
l 升级内存，增加数据缓存
l 升级存储与网络，使用磁盘IO的高带宽低时延解决方案
由于不能投入更多的资金来升级服务器硬件资源，因此无法提升数据库的性能指标。
传统数据库厂商Oracle的解决方案
l Outline
锁定一个给定SQL语句的执行计划，保持其执行计划稳定，不管数据库环境如何变更，Outline将执行计划的hint集合保存在outline的表中（数据字典）。当执行SQL解析时，Oracle会与outline中的SQL比较，如果该SQL有保存的outline，则通过保存的hint集合生成指定执行计划。
l DBMS_SQLTUNE
DBMS_SQLTUNE提供了SQL Profile功能用于影响SQL的执行计划，达到在不修改SQL的情况下优化SQL的目的。可以认为是Outline 的升级版本。
然而，这个传统解决方案只适用于通过HINT能解决的问题，如果需要修改SQL访问对象和SQL逻辑，则无法解决。
金仓KES的创意改造令人超惊喜！
令人惊奇的改造工具Query Mapping
Query Mapping 是一种查询映射功能。部分SQL性能问题，可能涉及到SQL层面的修改。然而SQL层面的修改不仅麻烦，在已上线的系统中还存在巨大的风险。
金仓数据库KingbaseES提供了Query Mapping功能，用户通过SQL映射，可避免直接修改SQL的过程。用高效的查询语句悄然替换不堪大用的低效查询语句。
TEXT级别
SEMANTICS级别
使用优化后的SQL代替原SQL，使用索引代替全表
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提供的性能优化工具，用户可以在不修改应用逻辑的情况下，达到快速解决性能问题的目的。通过语句映射，实现将用户的原始语句根据需要转换成用户想要的语句。
该工具使用简单，且通过内置的系统表记录映射信息，访问非常高效。
具体到实例，只需运行如下命令：
select create_query_rule('qm01', 'select user_privilege from xxx where ID=$1;’ , 'select user_privilege from xxx where ID=$1::text;', true, 'text'); |
通过创建SQL映射，优化器在解析SQL时，如遇到匹配的SQL，将自动对SQL进行转换，有效地避免了对于SQL的修改，整个应用的访问效率得到了非常大的提升。
原来必须通过修改代码的应用，如今仅需通过简单的数据库操作就可以解决。
当然，除了上述的SQL转换的例子，Query Mapping功能还可以广泛应用于其他诸多的场景。例如DBA常见的HINT调优，也可通过Query Mapping，实现不修改应用代码即解决性能问题。
比较 Oracle 固化执行计划方案 的差异
由于统计信息不断发生变化，SQL语句的执行计划往往不稳定。
当数据量变化，或者索引增加，DBA通常需要改变SQL语句才能改善应用系统的性能。
Oracle固化执行计划方案虽然可以解决数据库环境发生变化时的性能问题，但当涉及到数据结构时，则变得无能为力。
而金仓数据库KingbaseES Query Mapping 则可使用完全不同的SQL语句去替代原SQL语句，生成崭新的查询结果。既可优化查询语句，也能从不同的表和列获得结果。
拯救不开心，金仓KES Query Mapping 带你逆风飞翔！
运行多年的应用系统，累积了大量的历史数据。然而，日益庞大的历史数据也给系统性能带来严重的挑战，使得原本性能良好的应用系统逐渐变得不堪使用。而现在，Query Mapping功能可以给这些疲惫的老应用系统注入新的活力，拯救不开心，金仓KES Query Mapping带你逆风飞翔，破风而上！
