為什么MySQL在數(shù)據(jù)庫較大的時候分頁查詢很慢，如何優(yōu)化？使用合理的分頁方式以提高分頁的效率正如樓主所說，分頁查詢在我們的實際應用中非常普遍，也是最容易出問題的查詢場景。比如對于下面簡單的語句，一般想

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

使用合理的分頁方式以提高分頁的效率

正如樓主所說，分頁查詢在我們的實際應用中非常普遍，也是最容易出問題的查詢場景。比如對于下面簡單的語句，一般想到的辦法是在name，age，register_time字段上創(chuàng)建復合索引。這樣條件排序都能有效的利用到索引，性能迅速提升。

如上例子，當 LIMIT 子句變成 “LIMIT 100000， 50” 時，此時我們會發(fā)現(xiàn)，只取50條語句為何會變慢?

原因很簡單，MySQL并不知道第 100000條記錄從什么地方開始，即使有索引也需要從頭計算一次，因此會感覺非常的慢。

通常，我們在做分頁查詢時，是可以獲取上一頁中的某個數(shù)據(jù)標志來縮小查詢范圍的，比如時間，可以將上一頁的最大值時間作為查詢條件的一部分，SQL可以優(yōu)化為這樣：

若對你有所幫助，歡迎點贊、關注支持哦。

mysql大量數(shù)據(jù)查詢速度慢，sql語句求解？

這個問題和設計有關系， 簡單的sql優(yōu)化提升不了多少， 但是這個sql還是可以進一步優(yōu)化的利用索引， 用union all代替in， 如 select * from tab where id in (1，2)， 可寫成select * from tab where id = 1 union all select * from tab where id = 2但是上面的優(yōu)化起不到根本效果， 如果100萬 1000萬數(shù)據(jù)怎么辦， 難道每次都要全部查出來嘛， 那是不可能的， 而且你的頁面也不能全部都展示出來! 所有需要換個思路， 如， 將一個會員的訂單記錄查詢出來， 然后通過程序(java或者存儲過程)算出時間差， 按照上面再計算下一個會員

mysql表數(shù)據(jù)量太大，達到了1億多條數(shù)據(jù)，除了分庫分表之外，還有沒有其他的解決方式？

mysql在常規(guī)配置下，一般只能承受2000萬的數(shù)據(jù)量(同時讀寫，且表中有大文本字段，單臺服務器)。現(xiàn)在超過1億，并不斷增加的情況下，建議如下處理：

1 分表?？梢园磿r間，或按一定的規(guī)則拆分，做到查詢某一條數(shù)據(jù)庫，盡量在一個子表中即可。這是最有效的方法

2 讀寫分離。尤其是寫入，放在新表中，定期進行同步。如果其中記錄不斷有update，最好將寫的數(shù)據(jù)放在 redis中，定期同步

3 表的大文本字段分離出來，成為獨立的新表。大文本字段，可以使用NOSQL數(shù)據(jù)庫

4 優(yōu)化架構，或優(yōu)化SQL查詢，避免聯(lián)表查詢，盡量不要用count(*)， in，遞歸等消耗性能的語句

5 用內(nèi)存緩存，或在前端讀的時候，增加緩存數(shù)據(jù)庫。重復讀取時，直接從緩存中讀取。

上面是低成本的管理方法，基本幾臺服務器即可搞定，但是管理起來麻煩一些。

當然，如果整體數(shù)據(jù)量特別大的話，也不在乎投入費用的話，用集群吧，用TIDB吧