策略在存儲過程分頁

我有這個存儲過程返回各地100K至1M行，根據參數（查看或？）：策略在存儲過程分頁

CREATE PROCEDURE dbo.sp_doStuff 
    @userId bigint = 0, 
    @date datetime = null 
AS 
BEGIN 
    SET NOCOUNT ON; 

    SELECT 
     ... 
    from 
     ... 
    order by theDate DESC; 

END

此存儲過程是由Java方法通過JdbcTemplate的叫，並從那裏進行分頁。但是這很慢，考慮到sp_doStuff的平均執行時間已經是60秒了。

這就是這個sp_doStuff被用戶點擊的每一個下一頁按鈕（很慢）調用。它可以一次使用60秒，但下一頁不應該使用。如何在此SQL代碼中實現視圖（或任何解決方案應用程序），以便jdbcTemplate調用不必每次都處理這十萬行。

每一個按鈕被點擊時調用：

String sql = "MyDB..sp_doStuff '12345', '2013-01-24'" 
return jdbcTemplate.query(sql, new ResultSetExtractor<MyModel<Map<String, String>>>() { 
     @Override 
     public MyModel<Map<String, String>> extractData(ResultSet rs) 
       throws SQLException, DataAccessException { 
       .... 
     } 
    });

來源

2013-01-24 xybrek

視圖不會幫助 - 它只是一個視圖，將被「重新執行」。而且SP不能作爲索引視圖的基礎 - 所以也沒有。也許查詢 - 它是否需要成爲SP？請記住，這會對RA流量造成嚴重破壞！ - 可以加快分析和適當的指數/提示？我有*龐大而複雜的查詢*只需幾秒鐘即可運行。如果不是總體，也許可以在一定範圍內加快速度（例如每批分頁）。也許查詢可以保存在應用程序緩存中？也許這個查詢可以保存在一個臨時表中（這是一種緩存形式）？ – 2013-01-24 08:53:16

好的，如果我使用臨時表，那麼對於來自瀏覽器（來自多個用戶）的每個查詢，將爲每個查詢創建臨時表？乘以每個日期被查詢？ – xybrek

管理好了，是的，但它是一種方法。我建議首先在SP上運行性能分析，看看這個查詢是否可以「明顯加快」。也就是說，對於一般的「即時取景」結果集，60秒似乎太長了。一個簡單的不正確的哈希連接循環連接選擇（可能由缺乏變量嗅探引起）是混淆查詢規劃器的一種非常簡單的方法。 – 2013-01-24 09:00:31

很抱歉，但你真的應該顯示所有10萬行用戶頁面上???這看起來很瘋狂，真實的人從不分析現實生活中的100k行信息。如果你有1M的行並計算它們的值的AVG或其他值，但是從SP顯示給人是很不好的做法。從我的角度來看，您應該使用限制行和索引結果集的方法。例如：SELECT salary, date FROM USER_SALARY t WHERE t.id = '1748' ORDER BY date DESC LIMIT 29799, 100; 此請求將顯示來自USER_SALARY表的100行（起始行位置爲29800），用戶ID爲1748，按日字段排序（當然索引已由ID字段創建）我想，上述方法允許你可以使用應該在頁面上顯示給用戶的大數據表。

來源

2013-01-24 09:30:54

在我的問題中，我明確表示分頁是用java完成的 – xybrek

如果你的體系結構代碼不好 - 你應該改變這部分代碼，否則你的代碼會慢慢工作 –

策略在存儲過程分頁

回答

相關問題