一打開科技類論壇，最常看到的文章主題就是MySQL性能優(yōu)化了，為什么要優(yōu)化呢?

因為：

• 數(shù)據(jù)庫出現(xiàn)瓶頸，系統(tǒng)的吞吐量出現(xiàn)訪問速度慢
• 隨著應用程序的運行，數(shù)據(jù)庫的中的數(shù)據(jù)會越來越多，處理時間變長
• 數(shù)據(jù)讀寫速度緩慢

就是咱們說的“性能問題”，程序員一遇到它總是焦頭爛額!

今天小編對MySQL優(yōu)化總結(jié)了一些心得，希望在大家之后的工作中能有所有幫助!

示例二：

not in 和 not exist

如果查詢語句使用了not in 那么內(nèi)外表都進行全表掃描，沒有用到索引;而not exist 的子查詢依然能用到表上的索引。所以無論哪個表大，用not exists都比not in要快!

子查詢優(yōu)化

• MySQL 5.6 之前的版本對子查詢處理：不會將查詢的結(jié)果集計算出來用作與其他表做join,outer表每掃描一條數(shù)據(jù)，子查詢都會被重新執(zhí)行一遍。
• MySQL 5.6 對子查詢的處理 ：將子查詢的結(jié)果集 cache 到臨時表里，臨時表索引主要用來移除重復記錄，并且隨后也可能用于做join查詢，這種技術在 5.6 中叫做物化的子查詢，物化子查詢可以看到select_type字段為subquery，而在 5.5 里為DEPENDENT SUBQUERY。
• 子查詢一般都可以改成表的關聯(lián)查詢，子查詢會有臨時表的創(chuàng)建、銷毀，效率低下。

straight_join

mysql hint：

Mysql 優(yōu)化器在處理多表的關聯(lián)的時候，很有可能會選擇錯誤的驅(qū)動表進行關聯(lián)，導致了關聯(lián)次數(shù)的增加，從而使得sql語句執(zhí)行變得非常的緩慢。

這個時候需要有經(jīng)驗的DBA進行判斷，選擇正確的驅(qū)動表，這個時候 straightjoin 就起了作用了，下面我們來看一看使用straight_join進行優(yōu)化的案例：

嘗試采用user表做驅(qū)動表，使用straight_join強制連接順序：

高效分頁

傳統(tǒng)分頁：

select?*?from?table?limit?10000,10?

limit原理：

• Limit 10000,10
• 偏移量越大則越慢

推薦分頁：

復雜關聯(lián)SQL的優(yōu)化

• 首先查詢返回的結(jié)果集，通常查詢返回的結(jié)果集很少，是有優(yōu)化的空間的。
• 通過查看執(zhí)行計劃，查看優(yōu)化器選擇的驅(qū)動表，從執(zhí)行計劃的rows可以大致反應出問題的所在。
• 搞清各表的關聯(lián)關系，查看關聯(lián)字段是否有合適的索引。
• 使用straight_join關鍵詞來強制調(diào)整驅(qū)動表的選擇，對優(yōu)化的想法進行驗證。
• 如果條件允許，對復雜的SQL進行拆分。盡可能越簡單越好。

force index

有時優(yōu)化器可能由于統(tǒng)計信息不準確等原因，沒有選擇最優(yōu)的執(zhí)行計劃，可以人為改變mysql的執(zhí)行計劃，例如：

count的優(yōu)化

按照效率排序的話，count(字段)

總結(jié)

MySQL 性能優(yōu)化 最主要是理解 innodb 的索引原理及結(jié)構(gòu)及 SQL 的執(zhí)行計劃，在不斷累積經(jīng)驗的基礎上熟能生巧。

文章名稱：DBA大牛MySQL優(yōu)化心得
網(wǎng)站URL：http://chinadenli.net/news/100821.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、全網(wǎng)營銷推廣、營銷型網(wǎng)站建設、網(wǎng)站改版、品牌網(wǎng)站建設、虛擬主機

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)