mysql如何找出慢sql

long_query_time 參數(shù)的查看

創(chuàng)新互聯(lián)公司專注于企業(yè)全網(wǎng)營(yíng)銷推廣、網(wǎng)站重做改版、文峰網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5建站、商城網(wǎng)站制作、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為文峰等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。

默認(rèn)是10秒，10秒以上的sql會(huì)記錄?？蛇M(jìn)行值的修改，

long_query_time 默認(rèn)不開(kāi)啟 ，如果不是需要進(jìn)行開(kāi)始調(diào)優(yōu)，一般不建議開(kāi)啟此參數(shù)。

永久開(kāi)啟：

在my.cnf中的

1.查看慢查詢的時(shí)長(zhǎng)

看此圖默認(rèn)10秒，是大于10秒，不等于10秒。

2.修改此時(shí)長(zhǎng)

臨時(shí)修改，重啟mysql后失效，修改后需要新開(kāi)連接才能查詢到

永久在配制文件中修改

查看慢sql個(gè)數(shù)

將所有沒(méi)有使用帶索引的查詢語(yǔ)句全部寫(xiě)到慢查詢?nèi)罩局?/p>

設(shè)置沒(méi)帶索引的慢sql進(jìn)行記錄

最后匯總my.cnf配制

MySQL中如何查看“慢查詢”，如何分析執(zhí)行SQL的效率？

開(kāi)啟慢查詢?nèi)罩?/p>

mysql set global slow_query_log=1;

定義時(shí)間SQL查詢的超時(shí)時(shí)間

mysql set global long_query_time = 0.005;

查看慢查詢?nèi)罩镜谋４媛窂?/p>

mysql show global variables like 'slow_query_log_file';

查看慢查詢

cat /var/log/mysql/slow.log

如何查找MySQL中查詢慢的SQL語(yǔ)句

1、首先，要開(kāi)啟mysql的慢查詢?nèi)罩?。在mysql的配置文件:my.ini中添加如下兩個(gè)配置項(xiàng)：

log-slow-queries = E:\Servers\MySql5.5\data\mysql_slow_query.log //mysql慢查詢?nèi)罩居涗浳恢?/p>

long_query_time=5 //定義慢查詢sql的時(shí)間，當(dāng)前配置表示超過(guò)5秒的sql為慢查詢，進(jìn)入到日志里

2、查詢慢查詢?nèi)罩?/p>

找到配置的慢查詢?nèi)罩疚募?，如E:\Servers\MySql5.5\data\mysql_slow_query.log ，這里就是所有的慢查詢sql啦

MySQL查詢效率很慢的問(wèn)題如何分析和解決

MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤 IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。

如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。

臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。