自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

MySQL分頁(yè),求求你別再用offset和limit了!

數(shù)據(jù)庫(kù)
隨著時(shí)代的進(jìn)步,隨著野心勃勃的企業(yè)想要變成下一個(gè) Facebook,隨著為機(jī)器學(xué)習(xí)預(yù)測(cè)收集盡可能多數(shù)據(jù)的想法的出現(xiàn),作為開發(fā)人員,我們要不斷地打磨我們的 API,讓它們提供可靠和有效的端點(diǎn),從而毫不費(fèi)力地瀏覽海量數(shù)據(jù)。

不需要擔(dān)心數(shù)據(jù)庫(kù)性能優(yōu)化問題的日子已經(jīng)一去不復(fù)返了。

隨著時(shí)代的進(jìn)步,隨著野心勃勃的企業(yè)想要變成下一個(gè) Facebook,隨著為機(jī)器學(xué)習(xí)預(yù)測(cè)收集盡可能多數(shù)據(jù)的想法的出現(xiàn),作為開發(fā)人員,我們要不斷地打磨我們的 API,讓它們提供可靠和有效的端點(diǎn),從而毫不費(fèi)力地瀏覽海量數(shù)據(jù)。

如果你做過后臺(tái)開發(fā)或數(shù)據(jù)庫(kù)架構(gòu),你可能是這么分頁(yè)的:

如果你真的是這么分頁(yè),那么我不得不抱歉地說,你這樣做是錯(cuò)的。

你不以為然?沒關(guān)系。Slack、Shopify 和 Mixmax 這些公司都在用我們今天將要討論的方式進(jìn)行分頁(yè)。

我想你很難找出一個(gè)不使用 OFFSET 和 LIMIT 進(jìn)行數(shù)據(jù)庫(kù)分頁(yè)的人。對(duì)于簡(jiǎn)單的小型應(yīng)用程序和數(shù)據(jù)量不是很大的場(chǎng)景,這種方式還是能夠“應(yīng)付”的。

如果你想從頭開始構(gòu)建一個(gè)可靠且高效的系統(tǒng),在一開始就要把它做好。

今天我們將探討已經(jīng)被廣泛使用的分頁(yè)方式存在的問題,以及如何實(shí)現(xiàn)高性能分頁(yè)。

OFFSET 和 LIMIT 有什么問題?

正如前面段落所說的那樣,OFFSET 和 LIMIT 對(duì)于數(shù)據(jù)量少的項(xiàng)目來(lái)說是沒有問題的。

但是,當(dāng)數(shù)據(jù)庫(kù)里的數(shù)據(jù)量超過服務(wù)器內(nèi)存能夠存儲(chǔ)的能力,并且需要對(duì)所有數(shù)據(jù)進(jìn)行分頁(yè),問題就會(huì)出現(xiàn)。

為了實(shí)現(xiàn)分頁(yè),每次收到分頁(yè)請(qǐng)求時(shí),數(shù)據(jù)庫(kù)都需要進(jìn)行低效的全表掃描。

什么是全表掃描?全表掃描 (又稱順序掃描) 就是在數(shù)據(jù)庫(kù)中進(jìn)行逐行掃描,順序讀取表中的每一行記錄,然后檢查各個(gè)列是否符合查詢條件。這種掃描是已知最慢的,因?yàn)樾枰M(jìn)行大量的磁盤 I/O,而且從磁盤到內(nèi)存的傳輸開銷也很大。

這意味著,如果你有 1 億個(gè)用戶,OFFSET 是 5 千萬(wàn),那么它需要獲取所有這些記錄 (包括那么多根本不需要的數(shù)據(jù)),將它們放入內(nèi)存,然后獲取 LIMIT 指定的 20 條結(jié)果。

也就是說,為了獲取一頁(yè)的數(shù)據(jù):

10萬(wàn)行中的第5萬(wàn)行到第5萬(wàn)零20行

需要先獲取 5 萬(wàn)行。這么做是多么低效?

如果你不相信,可以看看這個(gè)例子:https://www.db-fiddle.com/f/3JSpBxVgcqL3W2AzfRNCyq/1?ref=hackernoon.com

?左邊的 Schema SQL 將插入 10 萬(wàn)行數(shù)據(jù),右邊有一個(gè)性能很差的查詢和一個(gè)較好的解決方案。只需單擊頂部的 Run,就可以比較它們的執(zhí)行時(shí)間。第一個(gè)查詢的運(yùn)行時(shí)間至少是第二個(gè)查詢的 30 倍。

數(shù)據(jù)越多,情況就越糟。看看我對(duì) 10 萬(wàn)行數(shù)據(jù)進(jìn)行的 PoC

https://github.com/IvoPereira/Efficient-Pagination-SQL-PoC?ref=hackernoon.com

現(xiàn)在你應(yīng)該知道這背后都發(fā)生了什么:OFFSET 越高,查詢時(shí)間就越長(zhǎng)。

替代方案

你應(yīng)該這樣做:

這是一種基于指針的分頁(yè)。

你要在本地保存上一次接收到的主鍵 (通常是一個(gè) ID) 和 LIMIT,而不是 OFFSET 和 LIMIT,那么每一次的查詢可能都與此類似。

為什么?因?yàn)橥ㄟ^顯式告知數(shù)據(jù)庫(kù)最新行,數(shù)據(jù)庫(kù)就確切地知道從哪里開始搜索(基于有效的索引),而不需要考慮目標(biāo)范圍之外的記錄。

比較這個(gè)查詢:

圖片

和優(yōu)化的版本:

圖片

返回同樣的結(jié)果,第一個(gè)查詢使用了 12.80 秒,而第二個(gè)僅用了 0.01 秒。

要使用這種基于游標(biāo)的分頁(yè),需要有一個(gè)惟一的序列字段 (或多個(gè)),比如惟一的整數(shù) ID 或時(shí)間戳,但在某些特定情況下可能無(wú)法滿足這個(gè)條件。

我的建議是,不管怎樣都要考慮每種解決方案的優(yōu)缺點(diǎn),以及需要執(zhí)行哪種查詢。

如果需要基于大量數(shù)據(jù)做查詢操作,Rick James 的文章提供了更深入的指導(dǎo)。

如果我們的表沒有主鍵,比如是具有多對(duì)多關(guān)系的表,那么就使用傳統(tǒng)的 OFFSET/LIMIT 方式,只是這樣做存在潛在的慢查詢問題。我建議在需要分頁(yè)的表中使用自動(dòng)遞增的主鍵,即使只是為了分頁(yè)。


責(zé)任編輯:華軒 來(lái)源: 數(shù)據(jù)前線
相關(guān)推薦

2021-06-09 06:41:11

OFFSETLIMIT分頁(yè)

2020-12-15 08:06:45

waitnotifyCondition

2020-12-11 09:24:19

Elasticsear存儲(chǔ)數(shù)據(jù)

2020-12-04 10:05:00

Pythonprint代碼

2020-12-02 11:18:50

print調(diào)試代碼Python

2020-06-15 08:12:51

try catch代碼處理器

2024-03-14 08:15:18

COUNT(*)數(shù)據(jù)庫(kù)LIMIT 1?

2020-11-09 08:22:29

程序員 IT科技

2024-06-12 13:54:37

編程語(yǔ)言字符串代碼

2020-12-07 06:05:34

apidocyapiknife4j

2021-05-11 07:10:18

標(biāo)準(zhǔn)庫(kù)DjangoOS

2020-09-22 09:05:45

MySQLUTF-8utf8mb4

2022-09-07 07:37:06

LIMITOFFSET分頁(yè)

2023-12-08 14:37:51

接口jar包開發(fā)

2021-01-29 11:05:50

PrintPython代碼

2020-12-03 09:05:38

SQL代碼方案

2023-10-26 16:33:59

float 布局前段CSS

2021-05-25 09:30:44

kill -9Linux kill -9 pid

2023-04-10 08:07:48

MySQLlimitoffset

2025-02-10 08:05:03

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)