一條sql突然執行變慢,耗時9秒,應用是不能改的,只能從資料庫方面下手解決
步驟思路:
1:查看sql是否走索引
2:查看索引是否失效
3:hint 強制走索引(只是用來查看hint狀態下,查詢是否更改,應用是不能改的)
4:收集該表所有信息(包括索引)
5:分析該表所有信息(包括索引)
6:再次執行並查看
注意:哪個用戶執行較慢,就用哪個用戶進行操作,這樣才准確
Ⅱ 關於MYSQL伺服器突然變慢的問題
MySQL 在崩潰恢復時,會遍歷打開所有 ibd 文件的 header page 驗證數據字典的准確性,如果 MySQL 中包含了大量表,這個校驗過程就會比較耗時。MySQL 下崩潰恢復確實和表數量有關,表總數越大,崩潰恢復時間越長。另外磁碟 IOPS 也會影響崩潰恢復時間,像這里開發庫的 HDD IOPS 較低,因此面對大量的表空間,校驗速度就非常緩慢。另外一個發現,MySQL 8 下正常啟用時居然也會進行表空間校驗,而故障恢復時則會額外再進行一次表空間校驗,等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性,即表數量超過 5W 時,會啟用多線程掃描,加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛?查閱了資料,方法主要有兩種:
配置 innodb_force_recovery可以使 srv_force_recovery != 0,那麼 validate = false,即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1,也就是強制恢復跳過壞頁,就可以跳過校驗,然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程,快速啟動 MySQL,個人目前暫時未發現有什麼隱患。
2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了,只需要打開一個 ibdata 文件即可,大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後,感覺共享表空間在很多業務環境下,反而更有優勢。
臨時冒出另外一種解決想法,即用 GDB 調試崩潰恢復,通過臨時修改 validate 變數值讓 MySQL 跳過表空間驗證過程,然後讓 MySQL 正常關閉,重新啟動就可以正常啟動了。但是實際測試發現,如果以 debug 模式運行,確實可以臨時修改 validate 變數,跳過表空間驗證過程,但是 debug 模式下代碼運行效率大打折扣,反而耗時更長。而以非 debug 模式運行,則無法修改 validate 變數,想法破滅。
Ⅲ ASP用ODBC連接Access資料庫查詢突然變慢
你的資料庫鏈接過多,或者你的數據可比較大!同時載入的東西過多!在與你資料庫同目錄里會產生一個.ldb後綴的文件!一般情況都會有這個文件,但是這個文件太大就會導致鏈接過慢,甚至鏈接不上,你重啟後,大量鏈接關閉,.ldb後綴的文件就沒了!所以,又能連接了!
建議資料庫不要超過30M ,如果需要的話換成SQL的比較好~
Ⅳ 如果一個linux上的oracle資料庫系統突然變慢,你一般從哪裡去查找原因
建議10G,linux本身就要2G,oracle4G左右,oracle的聯機日誌,閃回區增長的很快,所以要為數據文件留足空間
請參考
Ⅳ Access 資料庫 運行速度變慢,是什麼原因,如何恢復
是什麼網路啊 連區域網絡的 還是 外部網路 好象是中病毒了 (區域網按理說是中不了病毒的,但是在單位有的人總愛拿U盤等在工作站導資料 就中了)只是電腦慢也說不準有其他毛病,但我建議買本 新出 的〈電腦迷〉等書 用他帶的光碟啟動電腦在dos下殺毒