為什么MySQL在數(shù)據(jù)庫較大的時候分頁查詢很慢，如何優(yōu)化？正如房東所說，分頁查詢在我們的實際應(yīng)用中非常常見，也是問題最多的查詢場景。例如，對于下面的簡單語句，通常的思考方式是在name、age、reg

為什么MySQL在數(shù)據(jù)庫較大的時候分頁查詢很慢，如何優(yōu)化？

正如房東所說，分頁查詢在我們的實際應(yīng)用中非常常見，也是問題最多的查詢場景。例如，對于下面的簡單語句，通常的思考方式是在name、age、register中u在time字段上創(chuàng)建一個復(fù)合索引。這樣，條件排序可以有效地利用索引，性能得到快速提高。

如上例所示，當(dāng)limit子句變?yōu)椤發(fā)imit 100000，50”時，我們會發(fā)現(xiàn)，如果只選擇了50條語句，為什么會變慢？

，所以我們會覺得很慢。

如何使用使用分頁查詢來適應(yīng)挖掘海量數(shù)據(jù)呢？

分頁查詢。一般來說，DBA的思想是在某個（如ID、create等）時間字段中進行查詢。這樣，條件排序可以有效地利用索引，性能得到快速提高。因為如果limit子句變成“l(fā)imit 1000000，10”，你會抱怨：為什么我只錄了10張唱片，卻還慢？你知道，數(shù)據(jù)庫不知道1000000條記錄從哪里開始。即使有指標(biāo)，也需要從頭開始計算。當(dāng)出現(xiàn)這種性能問題時，大多數(shù)時候程序員是懶惰的。在前端數(shù)據(jù)瀏覽翻頁或大數(shù)據(jù)批量導(dǎo)出的場景中，可以將前一頁的最大值作為一個參數(shù)作為查詢條件。SQL重新設(shè)計如下：通過create從create time>“2017-07-04 09:00:00”O(jiān)RDER表格中選擇*這樣，查詢時間基本固定，不會隨著數(shù)據(jù)量的增長而變化。