嗯，這個一般和數據大小，硬盤寫入速度，內存，cpu處理速度有關。性能越高，在一條sql語句中處理的小塊數據就越多。2020-07-09:MySQL如何啟動慢速查詢？而mysqld可以通過配置log-s

嗯，這個一般和數據大小，硬盤寫入速度，內存，cpu處理速度有關。性能越高，在一條sql語句中處理的小塊數據就越多。

2020-07-09:MySQL如何啟動慢速查詢？

而mysqld可以通過配置log-slow-queriesfile-path來記錄慢速查詢，重啟后生效。

Mysqldumpslow，一個分析慢速查詢日志的工具，由mysql官方提供。主要功能包括統(tǒng)計類型、出現次數、最長執(zhí)行時間、累計總時間、等待鎖的時間、發(fā)送給客戶端的總行數、總行數、用戶數和sql語句本身。這樣可以快速定位問題點，也可以為下一條sql提供充分的參考。

有一些第三方工具，但我還沒有 我沒用過它們。好像有些GUI工具比較好用。你可以搜索他們。我不 我不能用它，因為我 我擔心在生產環(huán)境中部署更多的軟件會導致更多的安全漏洞。

希望你的回復會有幫助。

這個專業(yè)回答怎么配圖？為什么只有有圖的才能高質量回答？

查詢摘要

孔子說工欲善其事，必先利其器。 "

善于使用好的性能分析工具，可以讓運維效率事半功倍。Pt-query-digest是Percona Toolkit中的常用工具，用于分析MySQL數據庫的慢速日志、二進制日志和通用日志，也可以使用從tcpdump中捕獲的show

我來說說這個問題:

題目提到的查詢應該是這樣的:select * from a where id in(select id from b)。

對于這個sql語句，它的執(zhí)行計劃不是先查詢表B的所有id，然后再與表A的id進行比較..

Mysql會將in子查詢轉換成現有的相關子查詢，所以實際上相當于這個sql語句:select * from a where exists(select * from b 循環(huán)出表A中的每一條記錄并與表B進行比較，比較的條件是看表A中每一條記錄的id是否存在于表B中，如果存在，則返回表A中的這條記錄..

exists查詢的缺點是什么？

根據存在的實現原理，表A(外觀)你可以 如果不使用索引，您必須掃描整個表，因為您要從表A到表B查找數據，并且您必須使用表A中的數據在表B中查找(從表外到表內)，順序是固定的。

如何優(yōu)化？

索引。但是從上面的分析可以看出，索引只能建立在表B的id字段中，而不能建立在表A的id中，mysql可以 不要用它。

這樣優(yōu)化就夠了嗎？It it'還是有點短。

因為exists只能用表A到表B的數據(從表外到表內)查詢它的執(zhí)行計劃，雖然它可以在表B的id字段建立索引來提高查詢效率。

然而，你可以 t從表B到表A依次取數據，exists子查詢的查詢順序是固定的。

為什么反過來呢？

因為你首先可以確定的是，反過來的結果是一樣的。這就引出了一個更詳細的問題:當兩個表的id字段都有索引時，是表A查表B的效率高還是表B查表A的效率高？

如何進一步優(yōu)化？

將查詢修改為inner join連接查詢:select * from an inner join b on(但這還不夠，再往下看)。

為什么不用左連接和右連接？

此時，表之間的連接順序是固定的，

例如，左連接意味著必須先檢查左表并掃描整個表，然后逐個轉到另一個表，右連接也是如此。仍然不是最佳選擇。

為什么我可以只使用內部連接？

內連接中的兩個表，比如A內連接B，但是實際執(zhí)行順序和寫的順序無關，最后執(zhí)行的可能是B連接A，順序不固定。如果on條件字段有索引，也可以使用較高的索引。

那怎么才能知道A和B的執(zhí)行順序哪個更有效率呢？

你不 我不知道，我也不知道。誰知道呢？Mysql知道的。讓mysql自己判斷(查詢優(yōu)化器)。mysql查詢優(yōu)化器將評估每個案例的成本，并最終選擇最佳的一個作為執(zhí)行計劃。

在inner join的連接中，mysql會評估是用表A查表B更高效還是用表B查表A更高效，如果兩個表都有索引，mysql還會評估表A的條件字段上的索引效率更高還是表B的更高..

我們需要做的是對兩個表的連接條件的兩個字段進行索引，然后解釋，檢查執(zhí)行計劃，看mysql使用了哪個索引，最后去掉沒有使用索引的表的字段索引。