為什么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)化為這樣：

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

一個復雜的查詢sql速度會比把sql建立成視圖來查詢速度更快嗎？

如果是普通的視圖，與復雜SQL的查詢區(qū)別就在于視圖減少了復雜SQL長語句的傳輸，在99.99%的情況下你是很難測出兩者的區(qū)別，或者可以說在當下這些服務器和帶寬的狀態(tài)下，可以直接忽略這個細微的效率影響，當成一致即可。

樓上有人說到物化視圖，先說明，這個是在oracle里面才特有的一個視圖，它是占用物理存儲的，在MySQL里面是沒有物化視圖等手段，但是可以通過一個簡單的轉(zhuǎn)換達到差不多的效果，MySQL可以觸發(fā)器 存儲過程去跑出一個表，這個表映射出來查詢。

其實SQL的優(yōu)化要考慮比較多方面，結(jié)合起來處理才能真正消除慢SQL。

mysql多表查詢中，表的數(shù)量很大而且查詢條件很多，加視圖的話可不可以提高查詢速度呢？

視圖的方式可以“簡化”查詢邏輯，讓查詢看起來簡單，但是如果多表查詢性能差，對于視圖的方式來說，要排查性能瓶頸還是比較困難的。所以優(yōu)化的本質(zhì)不會變，是基于資源的平衡，簡化不能夠解決性能問題。

mysql優(yōu)化教程？

1、對SQL語句、索引、表結(jié)構(gòu)等進行優(yōu)化。

2、開啟查詢緩存，Query Cache緩存了SELECT查詢及其結(jié)果數(shù)據(jù)集，當執(zhí)行一個同樣的SELECT查詢時，MySQL會從內(nèi)存中直接取出結(jié)果，加快了查詢執(zhí)行速度、減小了數(shù)據(jù)庫的壓力。執(zhí)行SHOW VARIABLES LIKE "have_query_cache"可以查看MySQL查詢緩存是否打開，開啟查詢緩存只需配置my.cnf文件即可，具體如下：

query_cache_type = 1

query_cache_size = 128M

query_cache_limit = 1M

保存好后重啟MySQL。

3、選用InnoDB存儲引擎，MySQL常用存儲引擎是MyISAM和InnoDB，二者區(qū)別如下：

MyISAM

查詢速度快；

支持表級鎖，在上鎖期間表上不能進行其他操作；

支持全文檢索；

支持數(shù)據(jù)壓縮、自我復制、查詢緩存、數(shù)據(jù)加密；

不支持外鍵；

不支持事務，所以也就沒有COMMIT和ROLLBACK操作；

不支持集群數(shù)據(jù)庫。

InnoDB

支持行級鎖；

支持外鍵，對外鍵約束強制；

支持事務，可執(zhí)行COMMIT和ROLLBACK操作；

支持數(shù)據(jù)壓縮、自我復制、查詢緩存、數(shù)據(jù)加密；

可用在集群環(huán)境，但并不完全支持。InnoDB表可以轉(zhuǎn)換為NDB存儲引擎，這樣就能用在集群環(huán)境。