一个哥们给我打电话。他说系统中一直出现等待事件 read by other session 。而且该等待都是同一个sql引起的。比較紧急，请我帮忙远程看看。

远程过去之后，用脚本把 等待事件给抓出来

从图中看到 read by other session 是在执行同一个SQL , sql_id 是  1svyhsn0g56qd

于是查看执行计划

该SQL走的是 ILMCU 这个列的索引，过滤条件有4个列，可是仅仅走了一个列的索引。

先别管执行计划，先来看一下等待事件 read by other session 到底是被哪些进程堵塞，这些进程又在跑什么SQL

最后发现， 还是同一个SQL。 然后细致问了一下业务。原来该系统是一个 沙发厂的 ERP 系统。

前台的用户点击某个button。等了半天没响应，然后就一直点，一直点 就导致这个 SQL 一直反复的执行，

可是呢。这个SQL 跑不出结果，所以就产生大量的 read by other session

所以呢。终于优化这个SQL就能够解决该问题，跑的SQL 例如以下：

SELECT *  FROM PRODDTA.F4111 WHERE ((ILDCT = :1   AND ILFRTO = :2   AND ILMCU = :3   AND ILDOC = :4  )) ORDER BY ILUKID ASC

走的索引是 ILMCU 这个列的索引。首先看一下这个表一共同拥有多少行

一共同拥有250w行，那这个表事实上不大啊，搞多了数据仓库，一个表没有几十亿数据那还真不算大。如今来看一下 ILMCU 这个列数据分布

同志们想一下 为啥我要用 full 这个hint?

由于如今 有 n 个进程 在跑 刚才的 SQL，而且就是 ILMCU 这个列的索引

 要是这个时候我不加 full hint , 万一又走了 ILMCU 这个列的 索引，那不是火上浇油吗

而且 这个表一共才 250w条数据，走全表也没啥的，而且我不仅仅要看这个列数据分布，还要看其余3个列。那必须走全表了

终于发现 ILMCU 这个列分布 太他妈不均衡了， 问了一下 那哥们，如今的业务是不是做的 SF10 。他回答说是的 。

从250w里面去选142w ,走索引， 卧槽，那肯定死啦死啦的 ，肯定产生大量的 db file sequen read 等待 ，

说白了。 表统计信息有问题，没收集直方图。哎。懒得管统计信息了，帮他搞定再说

于是又连续查看剩下的过滤列的数据分布

然后看了一下他的的数据库版本号，11gR2 。跑在 IBM 小鸡鸡上面 。 由于是 11g 能够 online 创建 索引， 假设是 10g 不敢 online 创建 (10g 是假的online )

create index idx_F4111_docdctilmcufrto on F4111(ILDOC,ILDCT,ILMCU,ILFRTO) online nologging;

索引创建完之后，前台的用户 立刻就搞定了， 之前是 搞了一天 ，我晕

问题再 总结一下 ：

这个 ERP 系统没有dba维护，所以呢 表没收集统计信息。表也缺乏索引， 这个表呢是 系统一直都有的 。而且是一个核心表 ，由于没 dba ，他们不敢乱建立索引

刚開始数据量小，没问题。后来数据量越来越大，问题就来了。我看了一下 他那边全部的业务全都跑得慢。今天这个是跑了一天，没法忍受了才找人帮忙的

我仅仅能说老板太他妈抠门了。招个dba，去干1--2个月，然后找个借口把 dba开除了 不就得了吗哈哈。或者要不来我这里培训一下 哈哈。