最佳化mysql的記憶體

標籤：來講   大小   預設   copy   排序   last   手冊   log   校正   

Mysql佔用CPU過高的時候，該從哪些方面下手進行最佳化？
佔用CPU過高，可以做如下考慮：
1）一般來講，排除高並發的因素，還是要找到導致你CPU過高的哪幾條在執行的SQL，show processlist語句，尋找負荷最重的SQL語句，最佳化該SQL，比如適當建立某欄位的索引；
2）開啟慢查詢日誌，將那些執行時間過長且佔用資源過多的SQL拿來進行explain分析，導致CPU過高，多數是GroupBy、OrderBy排序問題所導致，然後慢慢進行最佳化改進。比如最佳化insert語句、最佳化group by語句、最佳化order by語句、最佳化join語句等等；
3）考慮定時最佳化檔案及索引；
4）定期分析表，使用optimize table；
5）最佳化資料庫物件；
6）考慮是否是鎖問題；
7）調整一些MySQL Server參數，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；
8）如果資料量過大，可以考慮使用MySQL叢集或者搭建高可用環境。
9）可能由於記憶體latch（泄露）導致資料庫CPU高
10）在多使用者高並發的情況下，任何系統都會hold不住的，所以，使用緩衝是必須的，使用memcached或者redis緩衝都可以；
11）看看tmp_table_size大小是否偏小，如果允許，適當的增大一點；
12）如果max_heap_table_size配置的過小，增大一點；
13）mysql的sql語句睡眠連線逾時時間設定問題（wait_timeout）
14）使用show processlist查看mysql串連數，看看是否超過了mysql設定的串連數（http://www.cnblogs.com/kevingrace/p/6226324.html）

下面分享一例遇到過的案例：
網站在高峰時段訪問，點擊頁面有點卡。登陸伺服器，發現機器負載有點高，並且mysql佔用了很高的CPU資源，如下:

 

MySQL負載居高不下，如果開啟了慢查詢日誌功能，最好的辦法就是針對慢查詢日誌裡執行慢的sql語句進行最佳化，如果sql語句用了大量的group by等語句，union聯集查詢等肯定會將mysql的佔用率提高。所以就需要最佳化sql語句

除了最佳化sql語句外，也可以做一些配置上的最佳化。在mysql中運行show proceslist;出現下面回顯結果：
1.查詢有大量的Copying to tmp table on disk狀態
明顯是由於暫存資料表過大導致mysql將暫存資料表寫入硬碟影響了整體效能。

Mysql中tmp_table_size的預設值僅為16MB，在當前的情況下顯然是不夠用的。
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 16777216 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.00 sec)

解決辦法：調整暫存資料表大小
1）進mysql終端命令修改，加上global,下次進mysql就會生效
mysql> set global tmp_table_size=33554432;
Query OK, 0 rows affected (0.00 sec)

再次登陸mysql
mysql> show variables like "%tmp%";
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| max_tmp_tables | 32 |
| slave_load_tmpdir | /tmp |
| tmp_table_size | 33554432 |
| tmpdir | /tmp |
+-------------------+----------+
4 rows in set (0.01 sec)

2）my.cnf設定檔修改
[[email protected] ~]# vim my.cnf
.....
tmp_table_size = 32M

重啟mysql
[[email protected] ~]# /etc/init.d/mysqld restart

2.show processlist;命令的輸出結果顯示了有哪些線程在運行，可以協助識別出有問題的查詢語句。比如下面結果：
Id User Host db Command Time State Info
207 root 192.168.1.25:51718 mytest Sleep 5 NULL
先簡單說一下各列的含義和用途，

第一列，id，一個標識，你要kill一個語句的時候很有用。

user列，顯示單前使用者，如果不是root，這個命令就只顯示你許可權範圍內的sql語句。

host列，顯示這個語句是從哪個ip的哪個連接埠上發出的。呵呵，可以用來追蹤出問題語句的使用者。

db列，顯示這個進程目前串連的是哪個資料庫 。

command列，顯示當前串連的執行的命令，一般就是休眠（sleep），查詢（query），串連（connect）。time列，此這個狀態持續的時間，單位是秒。

state列，顯示使用當前串連的sql語句的狀態，很重要的列，後續會有所有的狀態的描述，請注意，state只是語句執行中的某一個狀態，一個sql語句，已查詢為例，可能需要經過copying to tmp table，Sorting result，Sending data等狀態才可以完成，

info列，顯示這個sql語句，因為長度有限，所以長的sql語句就顯示不全，但是一個判斷問題語句的重要依據。
常見問題：
一般是睡眠串連過多，嚴重消耗mysql伺服器資源(主要是cpu, 記憶體)，並可能導致mysql崩潰。

解決辦法 ：
在mysql的配置my.cnf檔案中，有一項wait_timeout參數設定.即可設定睡眠連線逾時秒數，如果某個連線逾時，會被mysql自然終止。
wait_timeout過大有弊端，其體現就是MySQL裡大量的SLEEP進程無法及時釋放，拖累系統效能，不過也不能把這個指設定的過小，否則你可能會遭遇到“MySQL has gone away”之類的問題。
通常來說，把wait_timeout設定為10小時是個不錯的選擇，但某些情況下可能也會出問題，比如說有一個CRON指令碼，其中兩次SQL查詢的間隔時間大於10秒的話，那麼這個設定就有問題了（當然，這也不是不能解決的問題，你可以在程式裡時不時mysql_ping一下，以便伺服器知道你還活著，重新計算wait_timeout時間）：

MySQL伺服器預設的“wait_timeout”是28800秒即8小時，意味著如果一個串連的空閑時間超過8個小時，MySQL將自動斷開該串連。
然而串連池卻認為該串連還是有效(因為並未校正串連的有效性)，當應用申請使用該串連時，就會導致下面的報錯：
The last packet successfully received from the server was 596,688 milliseconds ago.
mysql> show variables like ‘wait_timeout‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

28800seconds，也就是8小時。
如果在wait_timeout秒期間內，資料庫連接(java.sql.Connection)一直處於等待狀態，mysql就將該串連關閉。這時，你的Java應用的串連池仍然合法地持有該串連的引用。當用該串連來進行資料庫操作時，就碰到上述錯誤。
可以將mysql全域變數wait_timeout的預設值改大。
查看mysql手冊，發現對wait_timeout的最大值分別是24天/365天(windows/linux)。

比如將其改成30天
mysql> set global wait_timeout=124800;
Query OK, 0 rows affected (0.00 sec)

 

最佳化mysql的記憶體