如果 比例很 在银行信息系统开发运维过程 中,科技部 门总会碰 小 ,一般没有优化的空间。以一个查 询为例 ,如果从一 到 系 统运 行 效 率 低 的 问题 。为 了减 少 系 统处 理 的 时 间 , 个10 0 万条记录的数据集中查询返回10 0 条信息 ,且运行 更快更好地为客户服务 ,银行科技部的人员会根据系统 时间很慢 ,那么这个查 询一般有优化 的空间 ;但是如果 运行的现状 ,分析能够提高运行效率的 “ 点”,有针对 要返 回l 0 ( 万条信息 ,虽然运行时问很慢 ,那么这个查 ) 性 地 进 行系 统 优 化 。一 般 来 讲 ,系 统 优 化的 “ ”包 括 点 询 一般 也 不 具 备优 化 的 空 间 。所 以针 对 某 个应 用 优化 之 网络 带 宽 、系统 硬 件 、数 据库 访 问等 。在 分 析 优化 的过 前 ,先 估算 一下 该 比 例 大小 ,可 以 判断 该 应 用是 否能 够 程 中,很多人员往往有失偏颇 ,不能抓住重点问题 ,只 优 化 或 者 预 知优 化 的效 果 有 多 大 。根 据 这 个 准则 判 断可 从升级硬件 ,拓宽 网络带宽等方面下功夫 ,而不是从系 以优 化 后 ,下 面 可 以按 照 “ 个步 骤 ”进 行优 化 的实 际 三 统优化最重要的方面——数据库优化上面考虑 ,或者数 工 作 。 据库优化不知如何下手 ,导致了系统优化的工作不见成 2 三个步 骤 :用索 引 、去游标 、改逻 辑 . ()使用合适的索引访问数据库表 1 使 用 索 引 访 问是 提 高 数据 库 性 能 的常 用 方 法 。使 用 效。因为大多数银行信 息系统使用大型关系数据库作为 持久 化 的工 具 ,系 统 应 用 逻 辑 或 者 使 用 C、Jv 等 开发 aa 语言实现 ,或 者使用数 据库存储过 程实现某 些业务进 合适 的索 引 ,数据 库 服 务 器就 会 通 过 访 问 “ 引块 ” 快 索 程 ,并且使用C、Jv 等开发 语言的实现最终体现在数 速定位要查询的数据块 ,从而获得特 定的记录 ,而不是 aa 据库调用上来 ,所以本文所述 的数据库优化主要是指数 按顺序访问数据块 ( 也就是通常说的表扫描 ) 获得特定 据库调用的优化 。 的记录 ,从而使数据库服务器 以比没有索 引快得多的速 度检 索特 定的 行 。 二 、数据 库 优 化 的准 则 和步 骤 银行信息系统的数据库表大都经过了长时间的实践 通过对各种数据库优化方法进行总结 ,我们认为可 考验 ,通常会建立符合业 务内容的索 引,但是在应用开 2l./ OOg 中国金融电 脑 53 发过程 中往往 由于开发人员不注意 ,造成数据库访问不 式使用大量的锁处理 ,从而大大减慢了数据库引擎的处 能使用合适 的索引 ,从而使数据库访问效率低下 ,影响 理速度 。解 决办法就是尽量 去掉 游标处理 ,变 “ 行处 系统 的运行 速 度 。解 决 该 问题就 要 对照 业 务处 理 过程 代 理 ” 为 “ 集处 理 ” ,必 要 时采 用 临时 表 保存 中间要 生 成 码 ,检查每条访问数据库语句中的查询条件是否涵盖索 的数据 。如果确实无法去除游标 ,那也要尽量减少在游 引中的字段 ,即是否使用了合适的索引进行访问。如果 标 中的处理步骤 ,使游标遍历 中的数据库操作最小化。 没有涵盖 ,则要通过增加查询语句的查询条件将有关字 例 如 : 段补齐 ,或者根据整体需求给要访问的数据库表增加新 的索引。如某业务处理要从机构柜员表 中查询某个机构 中某个 柜 员 的信 息 ,机 构 柜 员表 的 索 引包含 机 构代 码 和 De lr u o e e tc so c a e C c r f r s l c u t me i , a e c mp n i rd n m , o a yd fo c s o e i f ; r m u t m rn o Op n c cu ; e r _ 柜员代码 ,但是该系统设计初始的时候 ,规定柜员代码 W hl() i 1{ e F t h c c ri t &i , n me &c m p n i ; e c u n o d& a , o a y d 全行唯一 ,和机构代码没有关系。如果开发人员没有注 意到该数据库表索 引和 系统规定的小小区别 ,查询语句 就有可能写成: S l c e l r o e n m e p o e u e e t t le c d , a , h n n mb r f o t le i f e r m e l r n o wh r l r o e ‘ 0 0 ’ e e t l c d = 0 0 01 e e I (qc d = S NO F f s lo e = QL T OUND) ra ; be k Se e t c l c om p n a e i t & c m pa na e f o a yn m n o o ny m r m c mp n i f e e c o a y n o wh r omp n i =&c m p n i a yd o a y d; 那么这条查询语句就不能使用该表的索引 ,从而造 成查询效率低下 ,甚至可能造成死锁 。解决办法就是在 该查询语句 中增加查询条件——机构代码 ( 一般业务处 理 中机构 代码 是可 以随 时获 得 的 ): S l c e l r o e n m e p o n mb r f o t le i f e e t t le c d , a , h ne u e m e l r n o r whe e e l c r t l er ode = ‘ 0000 a br nc ode 0 l’ nd a hc = ‘0 0 ’ 0 0 01 这样修改就可以让该查询语句使用现有索引,船陕应 用处理流程 , 表的数据量越大 , 节省的访问时间越多。 ()尽 量避免 使 用游标 在 循环 中处 理数 据库 记录 2 数 据 库 操 作 语 句 大 部 分 都 是 以 “ ” 为操 作 对 象 集 的 ,比如sl t p a 、dlt、isr,一条指令处理 e c、u dt e e net e e e 多条数据 ,这才是数据库性能的核心 ,也只有发挥数据 库这种 “ 集”的处理模式 ,才能真正发挥数据库的数据 处理性能 。为了兼容一般的过程处理 ,数据库也提供 了 单条 记录 的 处理 模式 ,也就 是 “ 标 ”模 式 ,这 种模 式 游 方 便 了 习惯 过 程 处理 的 程序 员 ,同时也 给 数据 库处 理 性 能提供缓慢 的途径。数据库面向 “ 集”的处理 引擎根本 无法提升游标处理模式的性能 ,反而为这种低效率的模 5 中国金融电脑/ 009 4 21. I sr i t e d t a u s&i , a , o a yd n e t n o tmp a e v le ( d &n me&c mp n i , &c mp n n me; o a y a )} 这种低效率 的游标处理方式非常耗费运行时间 ,特 别是数据量非常 大的时候。解决方法就是 去除游标 ,使 用数据库提供的 “ 集处理”模式 : I s r n o t m pd t s l c . us o e i .a n me n e ti t e a e e e ta c t m rd .a . ac . om p n d,b. o pa yn m e Fr m us ome i o a a yi c m n a o c t r nf , c mpa y n o b W h r .o p n i = . o o n i f e e a c m a y d b c mp n i a yd l 条 记 录 万 ( 步骤3 媾毋 通过这样修改就 可以使用一行 代码处理原来一段游 标代码才能处理 的业务 ,但是执行 时间却带来几何级的 减少。当然这个游标的处理逻辑比较简单 ,只是用来说 明问题的 。从实践上来看没有出现不能去游标 的情况 , 只不 过 有 时候 “ ”处 理 语 句 非常 复 杂 ,不容 易帮 助 其 集 他 人 理解 业 务逻 辑 。 录 ()修改业务处理逻辑 ,减少无谓的数据库操作 3 暖 . 0 1 条 记录 .万 ( 骤l 步 0 1 条 记 录 .万 ( 骤2 步 、 蝌《 麟 01 . 万条记录 ( 步骤3 ) 醪 大部分银行业务处理都比较复杂 ,包括多个方面 的 内容 ,都需要多步操作才能完成一个整体 的业务流程 。 图2 业 务 步 骤 调 整 后 们可能碰 到某些报 表不能很好 的利用现有 业务表 的索 如果处理步骤安排 的不合理 ,就可能影响整个业务流程 引 ,在 这 种 情 况 下 如 果 单 独 为 这 一 个 报 表 建 立 一 个 索 处 理 的效 率 ,而 通过 修 改 不 合理 业 务处 理 的顺 序就 能 大 录. 幅度提高运行效率。下面分两种形式进行说明。 一 每 个 步骤 从 不 同 的数 据 库 表 中 访 问数 据 。这 里 需 要 机构生成报表所需要的数据 ,放入一个临时数据小表 , 遵 循 “ 小 结果 集 ”准 则 ,即前 面 步骤 的输 出结 果 集 尽 生成报表的时候只从这个临时小表中获取数据 ,从而减 最 曩 / 引 ,就 会 影 响业 务 表 的 日间运 行 效 率 ,所 以最 好 不 要 采 取 增 加 表 索 引 的方 法 。恰 当的解 决方 法 是 先行 取 得 各个 量保持最小 ,理想状 态时与最终输出结果集的大小保持 小对业务数据大表的访问次数。下面举例做一下对 比 , 相当。 因为该表不能使用良好的索 引,每一步骤 都需要遍历A 表 中的 1 万条 记 录 ,所 以优 化 前 我们 需要 读 取 记录 数为 O l万 + O + O = 0 ( 图 3 示 )。 0 l万 I万 3万 如 所 假 定A 、B 、c 都有 良好索 引 ,那 么总 共 读 写 表 表 表 记录 数 为 l 万 + 万+ .万= 11 ( 图 1 示 ),但是 0 l 01 l . 万 如 所 如 果我 们 调 整 该 流程 如 图2 ,那 么 我 们读 取 数据 库 记 后 录数则为01 01 01 03 ,通过对 比步骤调整 . 万+ .万+ . 万: . 万 前后读取数据库的记录数 ,因此该步骤调整可 以大幅提 高整个业务的运行速度 。 每个步骤都从相 同的大数据量表中读取数据。我们 经 常会 碰 到 这 种情 况 :夜 间批 量 需 要 为 每个 机 构生 成 各 1 0 记 录 0条 __ 1 0 记 录 0条 10 记录 0条 种各样 的报表 ,这些机构报表分别从同一个大数据量的 数据库表 中抽取数据 ,比如账户表 、日志表等 ,同时我 步 图 3 增 加 提 取 数 据 步 骤 前 ! / 21./ 009 中国金融电 脑 55 通过增加一个整理数据的步骤 ,我们只需要读取 记 录 数 为 :l 万+ 0 + 0 + 0 1万 ,这 样 一来 只用 原 0 3 03 03 0 0 囊 _--- 刍 ; 图4 增加提取数据步骤 后 来13 /的运行时间 。如果原来的业 务步骤需要几十次甚 至上百次去读取A 表的l 万条记录 ,那么改进后业务处 0 理 的时 间将会 是 以前 的几 十分 之 一 ( 图4 示 )。 如 所 现在很 多数据 库优 化的思路要 么太空 泛 ,只有指 导意 义 ,要 么太 细致 ,细致到难 以掌握 ,本文 旨在提 出一 种指 导 思路并给 出具体 方法 ,花 较小 的代 价带来最 大化的优 化 效率,相信如果银行各个系统,特别是一些批量运行的系 统 ,遵循本文提出的 “ 一个准则”、 “ 三个步骤”就能较 好的提高系统运行效率 ,获得更好的客户体验。