phoenix 分頁limit offset
offset 這個是phoenix新版本提供的屬性，但是存在效能問題，大資料的情況下是不推薦的。
我本來想試試offset，隨著數量增加，耗時會如何增加。
但這兩個不同的測試sql，讓我有了新發現：
兩條語句的執行計劃：
0: jdbc:phoenix:192.168.199.154> explain select login_date,email from T_EXTENSION_ALL_DATAS_LOGIN where login_date='2018-11-24' and country='China' order by created_date desc limit 5000 offset 20000; +---------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ | PLAN | EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS | +---------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ | CLIENT 1-CHUNK 25000 ROWS 1625000 BYTES SERIAL 1-WAY RANGE SCAN OVER IDX_T_EXTENSION_ALL_DATAS_LOGIN_DATE_COUNTRY_CREATED ['2018-11-24','China'] | 1625000 | 25000 | 0 | | SERVER FILTER BY FIRST KEY ONLY | 1625000 | 25000 | 0 | | SERVER OFFSET 20000 | 1625000 | 25000 | 0 | | SERVER 25000 ROW LIMIT | 1625000 | 25000 | 0 | | CLIENT 5000 ROW LIMIT | 1625000 | 25000 | 0 | +---------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ 5 rows selected (0.038 seconds) 0: jdbc:phoenix:192.168.199.154> explain select seq_id from T_EXTENSION_ALL_DATAS_SHOW where show_date='2018-11-24' order by seq_id desc limit 20 offset 20000; +--------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ | PLAN | EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS | +--------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ | CLIENT 1-CHUNK 20020 ROWS 14314300 BYTES SERIAL 1-WAY REVERSE RANGE SCAN OVER T_EXTENSION_ALL_DATAS_SHOW ['2018-11-24'] | 14314300 | 20020 | 0 | | SERVER FILTER BY FIRST KEY ONLY | 14314300 | 20020 | 0 | | SERVER OFFSET 20000 | 14314300 | 20020 | 0 | | SERVER 20020 ROW LIMIT | 14314300 | 20020 | 0 | | CLIENT 20 ROW LIMIT | 14314300 | 20020 | 0 | +--------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+--------------+ 5 rows selected (0.032 seconds)
你說 跳躍2W行，查詢5000條的速度快？ 還是 跳躍2W行，查詢20條的速度快？
offset 2W與 20W的結果如下：
select login_date,email from T_EXTENSION_ALL_DATAS_LOGIN where login_date='2018-11-24' and country='China' order by created_date desc limit 5000 offset 20000; -- 5,000 rows selected (0.416 seconds) select seq_id from T_EXTENSION_ALL_DATAS_SHOW where show_date='2018-11-24' order by seq_id desc limit 20 offset 20000; -- 20 rows selected (2.071 seconds) select login_date,email from T_EXTENSION_ALL_DATAS_LOGIN where login_date='2018-11-24' and country='China' order by created_date desc limit 5000 offset 200000; -- 5,000 rows selected (0.515 seconds) select seq_id from T_EXTENSION_ALL_DATAS_SHOW where show_date='2018-11-24' order by seq_id desc limit 20 offset 200000; -- 20 rows selected (20.508 seconds)
都是走RANGE SCAN 為什麼差距，這麼大呢？
原因在於：
IDX_T_EXTENSION_ALL_DATAS_LOGIN_DATE_COUNTRY_CREATED 這個二級索引，他比使用 T_EXTENSION_ALL_DATAS_SHOW 這種表row key索引，欄位內容要少很多，所以快。
-- 建立排序索引語法
CREATE INDEX IDX_T_EXTENSION_ALL_DATAS_LOGIN_DATE_COUNTRY_CREATED ON T_EXTENSION_ALL_DATAS_LOGIN(LOGIN_DATE,COUNTRY,CREATED_DATE DESC);
0: jdbc:phoenix:192.168.199.154> select * from IDX_T_EXTENSION_ALL_DATAS_LOGIN_DATE_COUNTRY_CREATED limit 1;
+--------------+------------+----------------------+-----------------+
| :LOGIN_DATE | 0:COUNTRY | 0:CREATED_DATE | :EMAIL |
+--------------+------------+----------------------+-----------------+
| 2018-11-24 | China | 2018-11-24 15:26:57 | [email protected] |
+--------------+------------+----------------------+-----------------+
那麼使用這種全域性的排序索引，4個欄位，offset，20W。只要0.5S。
由於這個條件只有50W的資料，只能這麼試試了。接近50W，耗時1S左右。
select login_date,email from T_EXTENSION_ALL_DATAS_LOGIN where login_date='2018-11-24' and country='China' order by created_date desc limit 5000 offset 495000;
-- 5,000 rows selected (1.025 seconds)結論：雖然分頁這些不推薦使用offset。但是某些小資料場景下，還是可以使用的。
推薦不超過50W的小資料集，可以使用offset。
相關推薦
phoenix 分頁limit offset
offset 這個是phoenix新版本提供的屬性，但是存在效能問題，大資料的情況下是不推薦的。 我本來想試試offset，隨著數量增加，耗時會如何增加。 但這兩個不同的測試sql，讓我有了新發現： 兩條語句的執行計劃： 0: jdbc:phoenix:192.1
分頁demo 前端+後臺 （union 與union all 的區別 以及分頁limit,offset的應用）
記重點 1.UNION去重且排序,UNION ALL不去重不排序。 2. sql 中 limit 與 limit，offset連用的區別 ① select * from table limit 2,1;
mongodb 分頁(limit)
記錄 tle log _id limit bsp () mit skip db.COLLECTION_NAME.find().limit(NUMBER) db.mycol.find().limit(3) db.mycol.find({},{"title":1,_id:0}
phoenix 分頁
測試資料 // 表結構 CREATE TABLE TMP_TRAVEL (ROWKEY VARCHAR PRIMARY KEY,INFO.SP VARCHAR,INFO.EP VARCHAR,INFO.ST VARCHAR,INFO.ET VARCHAR); CREATE S
MySQL分頁查詢 offset
mysql的分頁查詢一直都有個疑問，如果我要查詢第十頁的內容（偏移量offset 90），前面的90條內容在查詢過程中有沒有被查詢過，今天終於找到了答案。 其實mysql是先查詢前10頁（比如前100條），然後把前90條丟棄，返回需要的91到100條資料。資料
Hbase Phoenix 分頁
全部為mybatis.xml 內容 1.建立表 <insert id="createTable"> create table if not exists "FVE_VoucherStorage" ( "fid" varchar not null
如何優化Mysql千萬級快速分頁,limit優化快速分頁,MySQL處理千萬級資料查詢的優化方案！（zz）
MySQL資料庫優化處理實現千萬級快速分頁分析，來看下吧。 資料表 collect ( id, title ,info ,vtype) 就這4個欄位，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往裡面填
MySQL 單表分頁 Limit 效能優化
主要針對記錄非常多的表 常用分頁sql語句： select * from product limit start, count 當起始頁較小時，查詢沒有效能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執行時間（每頁取20條）， 如
MYSQL分頁limit速度太慢優化方法
在mysql中limit可以實現快速分頁，但是如果資料到了幾百萬時我們的limit必須優化才能有效的合理的實現分頁了，否則可能卡死你的伺服器哦。當一個表資料有幾百萬的資料的時候成了問題！如 * from table limit 0,10 這個沒有問題 當 limit 2000
mysql 使用技巧 分頁limit
mysql 分頁使用 limit關鍵字，limit x,y （x代表從哪條資料開始，y代表頁面大小。mysql第一條資料在limit計算時索引為0） limit 10 前10條 limit 0,10 從第1條開始的10條 limit 10,10 從第 11 條開始的 10 條 limit 100
laravel 自定義分頁 offset 和 limit 的使用
有一個 信息 代碼 自定義 快速 技術 多少 信息技術 只需要 laravel 本身有一個自帶的快速分頁方法 paginate，只需要傳入每頁顯示多少條數據就可以 了，但是如果想使用自定義從哪裏開始呢，這時候就可以使用offset 和 limit 的組合，offset 設置
mysql 分頁查詢limit中偏移量offset過大導致效能問題
在業務中經常會遇到關於分頁的需求，這就會經常會用到MySQL中的limit offset，rows來分段取出每頁中需要的資料。但是當資料量足夠大的時候，limit條件中的偏移量offset越大就越會導致效能問題，導致查詢耗時增加嚴重。先看一下測試：
Mysql分頁查詢limit逗號和offset 區別
SELECT keyword FROM `keywords` WHERE id='59' ORDER BY keyword LIMIT 2 OFFSET 1; 比如這個SQL ，這裡表示的是從第一條資料（不包括第一條）開始讀取2條資料。 -----
java 原始limit分頁
map blog com per control mapper 技術分享 png src controller配置 jsp mapper.xml java 原始limit分頁
mysql的OFFSET實現分頁
分頁 set mys fse sql mit offset bsp IT 使用limit 可以實現分頁比如 limit 0,5 是從1到5條， limit 5，5 是從,6到10條， 使用limit offset 時 limit 5 offset 0 從 1 到5
Mysql LIMIT 分頁
sql 格式 tro ron index strong mysq bsp ges 格式： LIMIT index, size // index：從哪一行（第幾條）開始查，size：多少條 分頁： LIMIT (currentPage-1)*pageSize, pag
MySQL---正確使用索引、limit分頁、執行計劃、慢日誌查詢
ngs 數據庫 配置 服務 esc 操作 com ora 條件 正確使用索引 數據庫表中添加索引後確實會讓查詢速度起飛，但前提必須是正確的使用索引來查詢，如果以錯誤的方式使用，則即使建立索引也會不奏效。即使建立索引，索引也不會生效： 1 - like ‘%xx‘ 2
offset fetch 分頁
SET STATISTICS IO ON SET STATISTICS TIME ON DECLARE @pageIndex INT=800,@pageSize INT=20 SELECT * FROM Person.Person AS t ORDER BY
使用mysql的limit進行分頁時出現重複問題
使用MySQL的limit進行分頁時，例如 select * from table_1 where 1=1 limit m,n 這樣後面的頁可能會出現重複資料，這時可以通過加入order by 子句來解決這種情況， select * from table_1 w
mysql 使用 limit 實現底層分頁（附原始碼）
原理解析： <select id="queryProductList" resultType="com.pojo.Product"> SELECT * FROM tb_product ORDER BY priority DESC LIMIT #{rowIndex},#{p