是這樣的，我們公司開(kāi)發(fā)人員都是使用navicat這個(gè)軟件的，平時(shí)開(kāi)發(fā)都是連接測(cè)試環(huán)境的mysql，測(cè)試環(huán)境的數(shù)據(jù)庫(kù)數(shù)據(jù)量很少，但現(xiàn)在有個(gè)不明白的現(xiàn)象：比如navicat打開(kāi)一張表，長(zhǎng)時(shí)間不去操作這張表，你再去操作（比如直接刷新操作）就會(huì)很卡差不多5秒后才出現(xiàn)數(shù)據(jù)，如下圖： 當(dāng)數(shù)據(jù)出來(lái)之后，再次刷新操作，又正常很快了；一段時(shí)間不操作，又會(huì)很卡，導(dǎo)致測(cè)試項(xiàng)目運(yùn)行也是卡卡的 其他增刪改查都會(huì)出現(xiàn)這種情況，因?yàn)槊繌埍頂?shù)據(jù)量只有1000條不到，應(yīng)該不會(huì)是數(shù)據(jù)量過(guò)大造成的。 不知道是不是mysql哪里配置有問(wèn)題還是什么的，我打印過(guò)SHOW PROCESSLIST也只有33條數(shù)據(jù)而已，如下圖： 打印SHOW VARIABLES; max_connections的值是5295，也沒(méi)有超出。show VARIABLES LIKE 'wait_timeout' 的值是28800，應(yīng)該不會(huì)自動(dòng)斷開(kāi) 還有我們公司都是使用vagrant的，centeos系統(tǒng)（不知道這個(gè)對(duì)mysql有沒(méi)有影響），幾個(gè)開(kāi)發(fā)人員都出現(xiàn)這種情況