42 consistent gets

　　计划是INDEX FULL SCAN (MIN/MAX)，(MIN/MAX)表明只会访问索引的头或尾，开销大大减小，只有42个一致读和极低的Cost，正常情况只能是

　　这个的两倍多。

　　马上动手改为:

　　SELECT

　　(select min(calltime) from analyse_content ),

　　(select MAX(calltime) from analyse_content )

　　FROM dual

　　Execution Plan

　　----------------------------------------------------------

　　Plan hash value: 2326664376

　　-----------------------------------------------------------

　　| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

　　-----------------------------------------------------------

　　| 0 | SELECT STATEMENT | | 1 | | 2 (0)| 00:00:01 | | |

　　| 1 | SORT AGGREGATE | | 1 | 8 | | | | |

　　| 2 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |

　　| 3 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

　　| 4 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

　　| 5 | SORT AGGREGATE | | 1 | 8 | | | | |

　　| 6 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |

　　| 7 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

　　| 8 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

　　| 9 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |

　　-------------------------------------------------------------

　　Statistics

　　----------------------------------------------------------

　　84 consistent gets

　　完美解决。

　　总结：

　　其实这个问题很小，这个SQL人人都会写，但是很多开发人员，在写这种SQL的时候不会去思考结果产生的过程，以实现为原则，在他们眼中数据库仍然是黑盒。在测试过程中也没有仔细观察效率，在测试表数据较少，人眼感觉不出来问题，一在生产库跑就越来越慢。

　　所以，无论是开发和DBA多学习数据库的执行机制和原理，是没有害处的。

转贴于：计算机等级考试_考试大

[1] [2]