某运营商一个超级SQL运行慢的问题

问题描述：

      某日，集成商的人联系我说，某个汇总出现了问题，数据库报出了如下错误信息：

老实说，当时并不太在意，以为无非就是SQL执行不了嘛，看看哪里报错就结束了。

后来发现问题很大：这个SQL的开始执行时间和报错退出之间差了将近2.5H。

检查数据库的相关情况，未见异常。

oncheck -cDI dbname:tabname的时候，发现了很多坏页，以为是坏页的问题，于是让用户重建表，重新导入数据。

但是问题依旧。

接下来开始正视这个问题了：

1、oncheck -cDI dbname:tabname肯定是可以过去的了；

2、索引也都是新建的，也能生效；

3、该表的行长是5.11KB，694个字段，汇总需要涉及477万行记录，该SQL涉及的select操作需要从磁盘上操作将近25GB数据；

4、insert into 插入的临时表通过观察，可以分散在4个临时dbs上，每个临时dbs 20GB，足够使用；

5、让集成商提取了一个正常汇总的日志，发现该步骤在正常时刻只需要11分钟即可完成；

6、有人建议让我创建一个裸表，insert into 裸表 select * from ...; 观察insert的效率如何，老实说，我没有做，因为意义不大；

7、我在做insert into 临时表 select * from ...;的时候，onstat -D观察，读取数据的dbs，明显发现dbs的读取性能不足，最快的时候不足10MB，而且还不能保证是只有这个表的IO；

做完上述动作，我的判断是磁盘IO性能不足所致。

 

通过跟踪集成商的日志，发现两个问题：

1、特意关闭了PDQ；这明显是不合理的；

2、分片表按天分片，是否应该按小时分片，每次执行天汇总的时候，打开PDQ，是否并发scan会更快；

3、创建完临时表之后就创建索引，应该先创建临时表，再insert数据，最后打开PDQ创建索引

上述3个问题，明显是DBA 的水平没有随着业务的深入而深入。

 

今天又被拉入一个大群讨论：

1、我已经明确告知排查存储的问题，比如存储的 cache是否关闭，存储是否有坏盘；

2、结果IBM的工程师告诉我，未见告警；我问是否可以保证存储的IOPS的性能，IBM工程师说可以保证主机和存储的链路正常；

3、我简直是醉了，客户估计也糊糊涂涂。。。。没有结果，可悲！

 

未完，待续。。。。。。

有结果了我再补上吧。

+++++++++++++++++++++++++++++++++++++++++++++++++++

今日继续补充：

1、一天的数据插入裸表，需要42分钟；

2、一天的数据插入临时表，需要48分钟；

我初步定为目前就是这个速度了，根本追不上11分钟的带索引插入的速度了。

先这么凑合用吧。

建议：

1、打开PDQ；

2、调整临时表创建的速度；