一直很糾結，Oracle的快速返回機制，雖然結果集很多，可是它能很快的顯示第一個結果，雖然通過MYSQl的客戶端可以做到，但是通過JDBC卻不行。

今天用了1個多小時，終於搞定此問題，希望對廣大Java朋友在處理資料庫時有個參考。

來由：

    通過命令列客戶端加上-q引數，可以極快的響應一個查詢。
    比如結果集為幾千萬的select * from t1，完整結果集需要20秒，通過-q引數顯示第一行只需要不到1秒。
    但通過jdbc進行查詢，卻不可以實現如上的效果，無論怎麼調整URL引數，也不行。
    
過程：
    查看了-q引數的解釋，如下：
    If you have problems due to insufficient memory for large result sets, 
    use the --quick option. This forces mysql to retrieve results 
    from the server a row at a time rather than retrieving the entire result set 
    and buffering it in memory before displaying it. This is done by returning 
    the result set using the mysql_use_result() C API function in the client/server 
    library rather than mysql_store_result().
    
    可見，實現快速響應。
    
    檢視 mysql_use_result() 函式，這個是C的API,如果通過C開發，可以用這個函式。
    
    那麼JAVA呢？
    
    查詢標準JDBC規範裡面有關函式，沒有任何收穫。 setFetchSize()看上去有效，可在實際測試裡，無任何效能提升。
    
    搜尋 JDBC mysql_use_result, 有了意外的收穫。
    
    在MYSQL的JDBC,com.mysql.jdbc.Statement 這個接口裡發現瞭如下的內容：
     abstract public  void disableStreamingResults() throws SQLException

    Resets this statements fetch size and result set type to the values they 
    had before enableStreamingResults() was called.

 abstract public  void enableStreamingResults() throws SQLException

    Workaround for containers that 'check' for sane values of Statement.setFetchSize() 
    so that applications can use the Java variant of libmysql's mysql_use_result() behavior. 
    
    
  原來MySQL提供了自己的一個快速響應的實現。調整測試程式碼