mysql伺服器巡檢腳本,linux伺服器巡檢腳本

本文目錄一覽：

• 1、如何編寫一個mysql資料庫腳本
• 2、MySQL資料庫伺服器逐漸變慢 該怎麼分析與解決
• 3、如何檢查mysql從資料庫是否正常運行，腳本

如何編寫一個mysql資料庫腳本

在控制台根目錄下打開sqlserver企業管理器，新建sqlserver組，根據自己的情況進行選擇；然後新建sqlserver

註冊，進行對sqlserver的連接。準備妥當後，下面就開始了：

首先打開數據轉換服務，新建包，打開dts界面，在連接中選擇數據源進行配置。再選擇將要轉換到的目的文件，這裡我選的

textfile(destination)，選擇好文件的存放位置之後，我們來新建一個任務。這裡我們只選擇轉換數據任務，將帶有「選擇源連接」「選擇目的連接」的滑鼠分別選中數據源和目的之後，我們對新生成的連接進行定義，在其屬性中將源，目的，轉換依次定義。

執行任務，提示成功。保存任務。然後在新建的任務上導出數據，有嚮導提示，其中一項選擇「從源資料庫複製表和視圖」。

這一步已經把數據導出到目的文件中。

下一步在mysql中新建表，與將要導入的結構保持一致時，直接選取「從文本文件中提取數據，插入到數據表：」，將選項添好後，「發送」就可以了，瀏覽一下，數據已導入了。若要導入的表已經存在，且屬性名也不同，這時就先建一個與要導入的數據相同結構的表並導入數據（按剛才的進行就可以了），然後在mysql中導出「數據和結構」，得到sql語句，將其在文本文件中編輯，利用文本編輯器的替換功能，將表名修改，列名加入，最後將其粘貼在要導入表的執行sql語句的地方，執行一下，數據便導入了。

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慢的診斷思路。

如何檢查mysql從資料庫是否正常運行，腳本

一般在從庫執行show slave status，看behind值是否為0來判斷。

更準確的一些的方法是在主庫做一個表，每秒insert一個時間戳，在從庫讀取，來看時間差是否超過1秒。