⑴ mysql數據量上十萬條後,查詢慢導致伺服器卡有什麼解決辦法
問題
我們有一個 SQL,用於找到沒有主鍵 / 唯一鍵的表,但是在 MySQL 5.7 上運行特別慢,怎麼辦?
實驗
我們搭建一個 MySQL 5.7 的環境,此處省略搭建步驟。
寫個簡單的腳本,製造一批帶主鍵和不帶主鍵的表:
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下:
1. 對於 information_schema 中的元數據表,執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫後的 SQL,我們猜測了優化器發生了誤判。
3. 我們增加了 hint,指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限於猜測,猜中了萬事大吉,猜不中就無法做出好的診斷。
⑵ mysql資料庫有100萬+數據,查詢起來很慢了,如何優化
你好,你可以根據條件去添加索引,例如:
一、
所有mysql索引列類型都可以被索引,對來相關類使用索引可以提高select查詢性能,根據mysql索引數,可以是最大索引與最小索引,每種存儲引擎對每個表的至少支持16的索引。總索引長度為256位元組。
mysim和innodb存儲引擎的表默認創建索引都是btree索引,目前mysql還不支持函數索引,但支持前緣索引,對欄位前N個字元創建索引
二、mysql創建索引語法
Create[unioun|fulltext|spatial]indexindexname[usingindextype]ontablename(tablenamecol)
index_col_name:
col_name[(length)][asc|desc]
如果你創建索引時搞錯了,需要修改mysql索引我們可以用alert來修改索引,語法與createindex創建索引差不多,我們就不說了,可以查看相關手冊。
下面我們來看一個關於mysql創建索引實例教程。
mysql>createindexcitynameoncity(city(2));
QueryOk,600rowsaffected(0.26sec)
Records:600Duplicates:0Warings0:
我們現在來以city為條件進行查詢,如下面。
->explainselect*fromcitywherecity='www.111cn.net'G
id:1
......
possible_keys:cityname
key:cityname
好了,現在我們來看看mysql刪除索引等實例
Dropindexnameontablename
實例,我現在要刪除剛才創建city索引
>dropindexcitynameoncity;
Queryok,.....
不過通常對百萬級數據的查詢或者其他操作,都改換其他的大型的資料庫了,希望能幫到你,望採納。
⑶ mysql資料庫操作耗時很久是什麼原因
Mysql查詢語句慢,執行時間長和等待時間長的原因
沒有索引或沒用好索引(單值索引和復合索引)
關聯查詢太多join,
伺服器調優及各個參數設置(緩沖,線程數等)
⑷ mysql資料庫突然變慢 資料庫變慢是什麼原因
MySQL 在崩潰恢復時,會遍歷打開所有 ibd 文件的 header page 驗證數據字典的准確性,如果 MySQL 中包含了大量表,這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關,表總數越大,崩潰恢復時間越長。另外磁碟 IOPS 也會影響崩潰恢復時間,像這里開發庫的 HDD IOPS 較低,因此面對大量的表空間,校驗速度就非常緩慢。另外一個發現,MySQL 8 下正常啟用時居然也會進行表空間校驗,而故障恢復時則會額外再進行一次表空間校驗,等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性,即表數量超過 5W 時,會啟用多線程掃描,加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛?查閱了資料,方法主要有兩種:
1. 配置 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 變數,想法破滅。
⑸ MySQL資料庫伺服器逐漸變慢分析與解決方法分享
一、檢查系統的狀態
通過操作系統的一些工具檢查系統的狀態,比如CPU、內存、交換、磁碟的利用率,根據經驗或與系統正常時的狀態相比對,有時系統表面上看起來看空閑,這也可能不是一個正常的狀態,因為cpu可能正等待IO的完成。除此之外,還應觀注那些佔用系統資源(cpu、內存)的進程。
1.使用sar來檢查操作系統是否存在IO問題
#sar-u210—
即每隔2秒檢察一次,共執行20次。
結果示例:
註:在redhat下,%system就是所謂的%wio。
Linux2.4.21-20.ELsmp
(YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
其中:
%usr指的是用戶進程使用的cpu資源的百分比;
%sys指的是系統資源使用cpu資源的百分比;
%wio指的是等待io完成的百分比,這是值得觀注的一項;
%idle即空閑的百分比。
如果wio列的值很大,如在35%以上,說明系統的IO存在瓶頸,CPU花費了很大的時間去等待I/O的完成。Idle很小說明系統CPU很忙。像以上的示例,可以看到wio平均值為11,說明I/O沒什麼特別的問題,而idle值為零,說明cpu已經滿負荷運行了。
2.使用vmstat監控內存
cpu資源
[root@mysql1
~]#
vmstat
procs
———–memory———-—swap–
—–io—-–system–
—–cpu——
r
b
swpd
free
buff
cache
si
so
bi
bo
in
cs
us
sy
id
wa
st
0
0
72
25428
54712672264
0
0
14
43
53
59
1
198
0
0
vmstat
的輸出那些信息值得關注?
io
bo:
磁碟寫的數據量稍大,如果是大文件的寫,10M以內基本不用擔心,如果是小文件寫2M以內基本正常
①
CPU問題
下面幾列需要被察看,以確定cpu是否有問題
Processesinthe
run
queue
(procs
r)
Usertime
(cpu
us)
System
time
(cpu
sy)
Idle
time
(cpu
id)
問題情況:
如果processes
in
run
queue
(procs
r)的數量遠大於系統中cpu的數量,將會使系統便慢。
如果這個數量是cpu的4倍的話,說明系統正面臨cpu能力短缺,這將使系統運行速度大幅度降低
如果cpu的idle時間經常為0的話,或者系統佔用時間(cpu
sy)是用戶佔用時間(cpu
us)兩輩的話,系統面臨缺少cpu資源
解決方案
:
解決這些情況,涉及到調整應用程序,使其能更有效的使用cpu,同時增加cpu的能力或數量
②內存問題
主要查看頁導入的數值(swap中的si),如果該值比較大就要考慮內存,大概方法如下:
最簡單的,加大RAM
減少RAM的需求
3.磁碟IO問題
處理方式:做raid10提高性能
4.網路問題
telnet一下MySQL對外開放的埠,如果不通的話,看看防火牆是否正確設置了。另外,看看MySQL是不是開啟了skip-networking的選項,如果開啟請關閉。