阿里雲mysql調試記錄,阿里雲mysql管理

本文目錄一覽：

• 1、阿里雲伺服器如何安裝MySQL資料庫
• 2、阿里雲cpu檢測進程mysql太高怎麼解決
• 3、阿里雲 mysql binlog 怎麼分析
• 4、阿里雲 MYSQL 總是崩潰，真誠尋求幫助
• 5、阿里雲伺服器連接mysql伺服器怎麼寫

阿里雲伺服器如何安裝MySQL資料庫

1.查看mysql編輯情況rpm -qa|grep mysql

2.卸載原有的mysql rpm -e –nodeps mysql　

 //

強力刪除模式，如果使用上面命令刪除時，提示有依賴的其它文件，則用該命令可以對其進行強力刪除

3.通過命令查看yum上面提供的可下載版本  yum list | grep mysql

4.安裝mysql客戶端和服務端 yum install -y mysql-server mysql mysql-deve

5.查看mysql啟動狀態 mysql service status

6.登錄mysql提示

7.修改mysql的root密碼

service mysqld stop

無密碼登錄mysql：mysqld_safe –skip-grant-tables

輸入mysql -uroot -p 直接回車進入mysql客戶端頁面

use mysql;

update user set password=PASSWORD(“root”)where user=”root”;修改密碼

flush privileges; 更新許可權

service mysqld restart

 最後直接登錄 mysql -u root -p回車輸入密碼

阿里雲cpu檢測進程mysql太高怎麼解決

一台伺服器解決了 Mysql cpu 佔用 100% 的問題。稍整理了一下，將經驗記錄在這篇文章里。

朋友主機(Windows 2003 + IIS + PHP + MYSQL )近來 MySQL 服務進程 (mysqld-nt.exe) CPU 佔用率總為 100% 高居不下。此主機有10個左右的 database, 分別給十個網站調用。據朋友測試，導致 mysqld-nt.exe cpu 佔用奇高的是網站A，一旦在 IIS 中將此網站停止服務，CPU 佔用就降下來了。一啟用，則馬上上升。

MYSQL CPU 佔用 100% 的解決過程

今天早上仔細檢查了一下。目前此網站的七日平均日 IP 為2000，PageView 為 3萬左右。網站A 用的 database 目前有39個表，記錄數 60.1萬條，占空間 45MB。按這個數據，MySQL 不可能佔用這麼高的資源。於是在伺服器上運行命令，將 mysql 當前的環境變數輸出到文件 output.txt：

d:\web\mysql mysqld.exe –help output.txt發現 tmp_table_size 的值是默認的 32M，於是修改 My.ini, 將 tmp_table_size 賦值到 200M:

d:\web\mysql notepad c:\windows\my.ini

[mysqld]

tmp_table_size=200M

然後重啟 MySQL 服務。CPU 佔用有輕微下降，以前的CPU 佔用波形圖是 100% 一根直線，現在則在 97%~100%之間起伏。這表明調整 tmp_table_size 參數對 MYSQL 性能提升有改善作用。但問題還沒有完全解決。

於是進入 mysql 的 shell 命令行，調用 show processlist, 查看當前 mysql 使用頻繁的 sql 語句：

mysql show processlist;

反覆調用此命令，發現網站 A 的兩個 SQL 語句經常在 process list 中出現，其語法如下：

SELECT t1.pid, t2.userid, t3.count, t1.dateFROM _mydata AS t1

LEFT JOIN _myuser AS t3 ON t1.userid=t3.useridLEFT JOIN _mydata_body AS t2 ON t1.pid=t3.pidORDER BY t1.pid

LIMIT 0,15

調用 show columns 檢查這三個表的結構 :

mysql show columns from _myuser;

mysql show columns from _mydata;

mysql show columns from _mydata_body;

終於發現了問題所在：_mydata 表，只根據 pid 建立了一個 primary key，但並沒有為 userid 建立索引。而在這個 SQL 語句的第一個 LEFT JOIN ON 子句中：

LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid_mydata 的 userid 被參與了條件比較運算。於是我為給 _mydata 表根據欄位 userid 建立了一個索引：

mysql ALTER TABLE `_mydata` ADD INDEX ( `userid` )建立此索引之後，CPU 馬上降到了 80% 左右。看到找到了問題所在，於是檢查另一個反覆出現在 show processlist 中的 sql 語句：

SELECT COUNT(*)

FROM _mydata AS t1, _mydata_key AS t2

WHERE t1.pid=t2.pid and t2.keywords = ‘孔雀’

經檢查 _mydata_key 表的結構，發現它只為 pid 建了了 primary key, 沒有為 keywords 建立 index。_mydata_key 目前有 33 萬條記錄，在沒有索引的情況下對33萬條記錄進行文本檢索匹配，不耗費大量的 cpu 時間才怪。看來就是針對這個表的檢索出問題了。於是同樣為 _mydata_key 表根據欄位 keywords 加上索引:

mysql ALTER TABLE `_mydata_key` ADD INDEX ( `keywords` )建立此索引之後，CPU立刻降了下來，在 50%~70%之間震蕩。

再次調用 show prosslist，網站A 的sql 調用就很少出現在結果列表中了。但發現此主機運行了幾個 Discuz 的論壇程序， Discuz 論壇的好幾個表也存在著這個問題。於是順手一併解決，cpu佔用再次降下來了。(2007.07.09 附註：關於 discuz 論壇的具體優化過程，我後來另寫了一篇文章，詳見：千萬級記錄的 Discuz! 論壇導致 MySQL CPU 100% 的 優化筆記 )解決 MYSQL CPU 佔用 100% 的經驗總結

增加 tmp_table_size 值。mysql 的配置文件中，tmp_table_size 的默認大小是 32M。如果一張臨時表超出該大小，MySQL產生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。 這是 mysql 官方關於此選項的解釋：

tmp_table_size

This variable determines the maximum size for a temporary table in memory. If the table becomes too large, a MYISAM table is created on disk. Try to avoid temporary tables by optimizing the queries where possible, but where this is not possible, try to ensure temporary tables are always stored in memory. Watching the processlist for queries with temporary tables that take too long to resolve can give you an early warning that tmp_table_size needs to be upped. Be aware that memory is also allocated per-thread. An example where upping this worked for more was a server where I upped this from 32MB (the default) to 64MB with immediate effect. The quicker resolution of queries resulted in less threads being active at any one time, with all-round benefits for the server, and available memory.

對 WHERE, JOIN, MAX(), MIN(), ORDER BY 等子句中的條件判斷中用到的欄位,應該根據其建立索引 INDEX。索引被用來快速找出在一個列上用一特定值的行。沒有索引，MySQL不得不首先以第一條記錄開始並然後讀完整個表直到它找出相關的行。表越大，花費時間越多。如果表對於查詢的列有一個索引，MySQL能快速到達一個位置去搜尋到數據文件的中間，沒有必要考慮所有數據。如果一個表有1000行，這比順序讀取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B樹中存儲。根據 mysql 的開發文檔:

索引 index 用於：

快速找出匹配一個WHERE子句的行

當執行聯結(JOIN)時，從其他表檢索行。

對特定的索引列找出MAX()或MIN()值

如果排序或分組在一個可用鍵的最左面前綴上進行(例如，ORDER BY key_part_1,key_part_2)，排序或分組一個表。如果所有鍵值部分跟隨DESC，鍵以倒序被讀取。

在一些情況中，一個查詢能被優化來檢索值，不用諮詢數據文件。如果對某些表的所有使用的列是數字型的並且構成某些鍵的最左面前綴，為了更快，值可以從索引樹被檢索出來。假定你發出下列SELECT語句：

mysql SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;如果一個多列索引存在於col1和col2上，適當的行可以直接被取出。如果分開的單行列索引存在於col1和col2上，優化器試圖通過決定哪個索引將找到更少的行並來找出更具限制性的索引並且使用該索引取行。

開發人員做 SQL 數據表設計的時候，一定要通盤考慮清楚。

阿里雲 mysql binlog 怎麼分析

RDS是阿里雲提供的即開即用的關係型資料庫服務，兼容了MySQL和SQL Server兩種資料庫引擎。在傳統資料庫的基礎上，阿里雲RDS提供了強大豐富的功能從而保證了高可用性、高安全性以及高性能。此外，RDS還提供了諸多便利功能提升了RDS的易用性。

★高可用：

採用主從熱備的架構。主機down機或者出現故障後，備機秒級完成無縫切換,服務可用性承諾：99.95%

提供自動多重備份的機制。用戶可以自行選擇備份周期，也可以根據自身業務特點隨時進行臨時備份,數據可靠性承諾：99.9999%

數據回溯到任意時間點。用戶可以選擇7天內的任意時間點創建一個臨時實例，臨時實例生成後驗證數據無誤，即可將數據遷移到RDS實例，從而完成數據回溯操作。

★高安全

提供白名單訪問策略。可自行設置允許訪問的IP及IP段，有效防止黑客掃描埠進行伺服器攻擊。

提供閾值報警的功能。支持實例鎖定報警、連接數報警、IOPS報警、磁碟空間使用報警、CPU報警等。

提供SQL注入告警。將對發往RDS的疑似SQL注入的語句進行記錄並展示，供用戶進行程序調整，杜絕SQL注入的發生。

SQL審計。記錄所有發往RDS的SQL語句，系統將記錄SQL語句相關的連接IP、訪問資料庫的名稱、執行語句的賬號、執行時間、返回記錄數等信息。供用戶對RDS安全性進行排查。

控制台操作日誌。記錄所有在控制台上進行的修改類操作，便於管理員查看並管理RDS。

阿里雲 MYSQL 總是崩潰，真誠尋求幫助

MYSQL崩潰的話，你需要把mysql 的 err 日誌貼出來。另外，你用的阿里雲的MYSQL，那就可以讓阿里雲的服務人員幫你解決，這個是你的權利。

阿里雲伺服器連接mysql伺服器怎麼寫

1.首先清除5.1版本的多餘包（有些阿里雲版本系統里有殘留）

yum -y remove mysql-libs-5.1*;

2.安裝mysql5.5伺服器端程序，

下載地址：

rpm -ivh MySQL-server-5.5.34-1.linux2.6.x86_64.rpm

3.安裝mysql5.5客戶端端程序

下載地址：

rpm -ivh MySQL-client-5.5.34-1.linux2.6.x86_64.rpm

4.然後啟動

service mysql start

多個系統測試過，這個版本最穩定，最不容易出現網上所說的各種問題