SQL优化典型案例分析资料.doc

关键字：充分利用过滤条件 原始sql查询 SELECT DISTINCT AS rowid, AS id, a.cstguid, b.cstname, Isnull(b.cardid,) AS cardid, Isnull(b.mobiletel,) + + Isnull(b.hometel,) + + Isnull(b.officetel,) AS lxtel, AS oppguid, a.buguid, AS projguid, c.memlevel, c.memcode, c.memguid, c.buguid AS hjbuguid, AS username, AS userguid, d.buname AS hjbuname FROM p_cstattach a LEFT JOIN p_customer b ON a.cstguid = b.cstguid LEFT JOIN h_member c ON b.cstguid = c.cstguid AND c.memstatus = 正式会员 LEFT JOIN mybusinessunit d ON c.buguid = d.buguid WHERE (1 = 1) AND (Isnull(b.mobiletel,) + + Isnull(b.hometel,) + + Isnull(b.officetel,) LIKE ) 优化前的IO 表Worktable。扫描计数0，逻辑读取0 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 表h_Member。扫描计数1，逻辑读取4818 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 表p_CstAttach。扫描计数1，逻辑读取12897 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 表p_Customer。扫描计数1，逻辑读取27222 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 表myBusinessUnit。扫描计数1，逻辑读取6 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。 优化过程分析 第一步：从业务角度分析。这里要找手机号码客户，拥有该手机号码的客户不会很多，为什么会有这么高的IO呢？很可能没有利用到索引，扫描产生这么大的IO； 第二步：看一下执行计划。确实是索引扫描。那么，有过滤条件为什么没有利用到索引呢？ 第三步：分析一下sql。过滤条件不符合 sARG规范：1、过滤条件左侧有函数；2、like条件左侧有百分号(%)；怎么办？ 第四步：再分析业务。操作员什么情况下会对手机号码做模糊查询？可能是这种情况：异地手机录入时前面加了0。买房人有多少使用异地手机呢？我统计了一下wk2008_5_13日的数据库，异地手机只占0.65%。为了满足0.65%的查询准确性牺牲99.35%查询性能有些不值得(； 第五步：我们能否这样改造呢？在普通查询中提供手机号码的精确查询，满足99.35%查询要求，在高级查询中使用模糊查询，满足另外0.65%的查询。 改造后的sql查询 SELECT DISTINCT AS rowid, AS id, a.cstguid, b.cstname, Isnull(b.cardid,) AS cardid, Isnull(b.mobiletel,) + + Isnull(b.hometel,) + + Isnull(b.officetel,) AS lxtel, AS oppg