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配置文件修改
[root@www ~]# vim my.cnf
.....
tmp_table_size = 32M
重啓mysql
[root@www ~]# /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)
自己的項目遇到的問題：
1.sql查詢如下 之前只加了單索引後面加了聯合索引 is_del和id_number 、is_del和code的索引以及優化了sql 把find_in_set改爲了LOCATE('dfs',p.code)>0
2、修改數據庫連接池，我用的是c3p0 增大連接數爲100，初始改爲10個
3.設置mysql表空間大小爲200M,因爲單表數據以及超過四十多萬條了，之前是默認設置16M的。