伺服器mysql的問題（伺服器mysql異常停止）

本文目錄一覽：

• 1、MySQL資料庫伺服器逐漸變慢 該如何分析與解決
• 2、啟動MySql伺服器失敗怎麼辦？
• 3、伺服器mysql資料庫老自動停止，請問怎麼回事
• 4、mysql伺服器無效怎麼解決
• 5、伺服器上提示mysql伺服器啟動失敗怎麼回事
• 6、MySQL資料庫伺服器逐漸變慢 該怎麼分析與解決

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伺服器失敗怎麼辦？

怎麼解決mysql服務無法啟動的問題

一：服務啟動

1.我們可以在Windows搜索欄中搜索服務應用功能，或者其他方式打開服務，右鍵單擊選擇以管理員運行。

2.在服務中找到MySQL，手動點擊啟動。

不過用這個方法很可能還是無法啟動mysql服務。

二：刪除Data

伺服器mysql資料庫老自動停止，請問怎麼回事

伺服器mysql資料庫老自動停止是因為在設置時出現了問題，解決方法為：

1、首先登陸伺服器。

2、登陸MySQL資料庫；命令如下：mysql -u root -p pwd。

3、查詢MySQL資料庫是否允許遠程ip訪問。

4、開啟遠程訪問操作。命令如下：GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’IDENTIFIED BY ‘111qqqpwd’ WITH GRANT OPTION;FLUSH PRIVILEGES。

5、打開navicate客戶端，新建mysql鏈接。

6、輸入遠程MySQL資料庫鏈接信息，點擊測試鏈接。資料庫鏈接成功。

注意事項：

MySQL 軟體採用了雙授權政策，分為社區版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇 MySQL 作為網站資料庫。

mysql伺服器無效怎麼解決

1.遇到這個問題先不要重新安裝MySQL資料庫，解決方法需要清理下WIndows的緩存目錄就可以了。

2.按「windows鍵+R」打開運行對話框，輸入命令「cmd」，回車打開DOS窗口。

3.輸入「del c:windowstemp*.* /s /q」，等待文件刪除完，MySQL自然會恢復正常。

二，配置文件配置錯誤(mysql啟動錯誤1067的解決 )

問題一

刪除%windows%/my.ini 刪除其它地方的my.ini 在mysql安裝目錄下把my-small.ini複製為my.ini 在my.ini

最後一行插入： CODE: [mysqld] #設置basedir指向mysql的安裝路徑

basedir=C:mysql-5.1.11-beta-win32 datadir=C:mysql-5.1.11-beta-win32data

重新啟動。。。

C:mysql-5.1.11-beta-win32innet start mysql MySQL

服務正在啟動 . MySQL 服務無法啟動。 系統出錯。

發生系統錯誤 1067。 進程意外終止。

C:mysql-5.1.11-beta-win32inmysqld-nt –remove Service successfully removed.

C:mysql-5.1.11-beta-win32inmysqld-nt –install Service successfully installed.

C:mysql-5.1.11-beta-win32innet start mysql MySQL 服務正在啟動 . MySQL 服務已經啟動成功。 C:mysql-5.1.11-beta-win32innet stop mysql MySQL 服務正在停止.. MySQL 服務已成功停止。

問題二

Mysql裝好後，重啟電腦第二次發現服務無法啟動。提示如下：

————————

MySQL 服務無法啟動。

系統出錯。

發生系統錯誤 1067。

進程意外終止。

——————

查看了F:ProgramDataMySQLMySQL Server 5.5data 這個目錄中的錯誤日誌，顯示如下內容：

130825 20:47:50 [Note] Plugin ‘FEDERATED’ is disabled.

130825 20:47:50 InnoDB: The InnoDB memory heap is disabled

130825 20:47:50 InnoDB: Mutexes and rw_locks use Windows interlocked functions

130825 20:47:50 InnoDB: Compressed tables use zlib 1.2.3

130825 20:47:50 InnoDB: Error: unable to create temporary file; errno: 2

130825 20:47:50 [ERROR] Plugin ‘InnoDB’ init function returned error.

130825 20:47:50 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.

130825 20:47:50 [ERROR] Unknown/unsupported storage engine: INNODB

130825 20:47:50 [ERROR] Aborting

其中核心提示是這句，臨時文件無法創建：

130825 20:47:50 InnoDB: Error: unable to create temporary file; errno: 2

因此查看my.ini

[mysqld]區段內加入：

#自己指定的臨時文件目錄

tmpdir=”臨時目錄”

伺服器上提示mysql伺服器啟動失敗怎麼回事

一、無法訪問系統資源

MySQL 不能訪問啟動需要的資源是造成而 MySQL 無法啟動的一個常見原因，如：文件，埠等。由於 linux 中用於啟動 mysqld 進程的 mysql 用戶通常是不能登陸的，可以使用類似下面的命令檢查文件的訪問許可權。

sudo -u mysql touch /var/lib/mysql/b

找出問題後，修改對應文件或目錄的許可權或屬主後通常可以解決問題。但有時 mysql 用戶有訪問文件和目錄的許可權，但仍然會被拒絕訪問，例如下面這個例子：

mysql system sudo -u mysql touch /home/mysql/data/a

mysql create table t1 (

id int primary key,n varchar(10

) data directory

ERROR 1030 (HY000): Got error 168 from storage engine

測試說明 mysql 用戶有這個目錄的訪問許可權，但創建文件還是失敗，這種情況讓很多人困惑，這個時候通常是 mysqld 進程的訪問被 linux 的 selinux 或 apparmor 給阻止了，大家可以看到創建的表不是在 mysql 的默認目錄下面，因此 selinux 或 apparmor 的 policy 裡面沒有包含這個目錄的訪問許可權，此時只要對應的修改 policy 就行了，當然把 selinux 或 apparmor 停了也行。

有時雖然對系統資源有訪問的許可權，但系統資源已經被佔用：

mysqld –no-defaults –console –user mysql

2020-11-03T03:36:07.519419Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.19) starting as process 21171

2020-11-03T03:36:07.740347Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

這個故障產生的原因是另外一個 mysqld 進程已經啟動並佔用了對應的文件。

二、參數設置錯誤

參數設置錯誤造成 MySQL 無法啟動的原因也非常常見，此時先要檢查 MySQL 啟動時會調用的參數，下面的命令可以查詢 MySQL 啟動時調用參數文件的順序：

$ mysqld –verbose –help | grep “Default options ” -A 1

Default options are read from the following files in the given order:

/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

知道了 MySQL 參數文件的調用順序，我們就可以檢查對應的參數文件，找出其中的錯誤，如果覺得參數文件的可讀性不強，可以使用下面的命令顯示 mysqld 程序將要調用的參數：

$ mysqld –print-defaults

/usr/sbin/mysqld would have been started with the following arguments:

……

注意這個命令顯示完參數後就退出，不會真正運行 mysqld。這個命令和 my_print_defaults mysqld 完全是等價的，只不過後者的顯示方式是一行一個參數。

然後開始對可疑的參數進行調試，我個人喜歡加的參數和順序如下：

1. 在 mysqld 後加上第一個參數 –no-defaults ，這個參數的作用是通知 mysqld 在啟動的時候不要讀任何參數文件；

2. 第二個參數是 –console，這個參數會把錯誤信息輸出到屏幕上，這個參數帶來的一個弊端是所有的信息都輸出到屏幕上，讓屏幕顯得比較亂，但對於我們調試卻是很方便的；

3. 第三個參數是 –log-error-verbosity=3，這個參數會顯示詳細的日誌；

4. 然後再在後面加上有把握的參數，可以一次只加一個參數，然後啟動 mysqld，採用排除法逐步找出錯誤的參數。

MySQL資料庫伺服器逐漸變慢 該怎麼分析與解決

我們先來看第一個階段，MySQL慢的診斷思路，一般我們會從三個方向來做：

第一個方向是MySQL內部的觀測

第二個方向是外部資源的觀測

第三個方向是外部需求的改造

1.1 MySQL 內部觀測

我們來看MySQL內部的觀測，常用的觀測手段是這樣的，從上往下看，第一部分是Processlist，看一下哪個SQL壓力不太正常，第二步是explain，解釋一下它的執行計劃，第三步我們要做Profilling，如果這個SQL能再執行一次的話, 就做一個Profilling，然後高級的DBA會直接動用performance_schema ，MySQL 5.7 以後直接動用sys_schema，sys_schema是一個視圖，裡面有便捷的各類信息，幫助大家來診斷性能。再高級一點，我們會動用innodb_metrics進行一個對引擎的診斷。

除了這些手段以外，大家還提出了一些亂七八糟的手段，我就不列在這了，這些是常規的一個MySQL的內部的狀態觀測的思路。除了這些以外，MySQL還陸陸續續提供了一些暴露自己狀態的方案，但是這些方案並沒有在實踐中形成套路，原因是學習成本比較高。

1.2 外部資源觀測

外部資源觀測這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國外的一個神寫的，標題是：60秒的快速巡檢，我們來看一下它在60秒之內對伺服器到底做了一個什麼樣的巡檢。一共十條命令，這是前五條，我們一條一條來看。

1.uptime，uptime告訴我們這個機器活了多久，以及它的平均的負載是多少。

2.dmesg -T | tail，告訴我們系統日誌裡邊有沒有什麼報錯。

3.vmstat 1，告訴我們虛擬內存的狀態，頁的換進換出有沒有問題，swap有沒有使用。

4. mpstat -P ALL，告訴我們CPU壓力在各個核上是不是均勻的。

5.pidstat 1，告訴我們各個進程的對資源的佔用大概是什麼樣子。

我們來看一下後五條：

首先是iostat-xz 1，查看IO的問題，然後是free-m內存使用率，之後兩個sar，按設備網卡設備的維度，看一下網路的消耗狀態，以及總體看TCP的使用率和錯誤率是多少。最後一條命令top，看一下大概的進程和線程的問題。

這個就是對於外部資源的診斷，這十條命令揭示了應該去診斷哪些外部資源。

1.3 外部需求改造

第三個診斷思路是外部的需求改造，我在這裡引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規的SQL怎麼寫, 給出了一些例子。文章的鏈接二維碼在slide上。

我們來看一下它其中提到的一個例子。

它做的事情是從一個表裡邊去選取，這張表有三列，article、dealer、price，選取每個作者的最貴的商品列在結果集中，這是它的最原始的SQL，非常符合業務的寫法，但是它是個關聯子查詢。

關聯子查詢成本是很貴的，所以上面的文檔會教你快速地把它轉成一個非關聯子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒有關聯性的。

第三步，會教大家直接把子查詢拿掉，然後轉成這樣一個SQL，這個就叫業務改造，前後三個SQL的成本都不一樣，把關聯子查詢拆掉的成本，拆掉以後SQL會跑得非常好，但這個SQL已經不能良好表義了，只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。

為什麼它能夠把一個關聯子查詢拆掉呢？

這背後的原理是關係代數，所有的SQL都可以被表達成等價的關係代數式，關係代數式之間有等價關係，這個等價關係通過變換可以把關聯子查詢拆掉。

上面的這篇文檔是一個大學的教材，它從頭教了關於代數和SQL之間的關係。然後一步步推導怎麼去簡化這句SQL。

第一，MySQL本身提供了很多命令來觀察MySQL自身的各類狀態，大家從上往下檢一般能檢到SQL的問題或者伺服器的問題。

第二，從伺服器的角度，我們從巡檢的腳本角度入手，伺服器的資源就這幾種，觀測手法也就那麼幾種，我們把伺服器的資源全部都觀察一圈就可以了。

第三，如果實在搞不定，需求方一定要按照資料庫容易接受的方式去寫SQL，這個成本會下降的非常快，這個是常規的MySQL慢的診斷思路。