安定北京
被性能測試困擾了N天，實在沒想法去解決了，今天又收到上級的命令說
安定北京
要解決，無奈！把項目組惟一的DBA辭掉了，如今因此數據庫的問題都得本身來處理：（ 不知道上邊人怎麼想的。並且更不知道怎
安定北京
麼想的是竟然會把應用部屬在虛擬主機上！唉。。。 不嘮叨了 說說處理過程吧： 1.在終端裏set profiling=1; 2.輸入要調整的SQL語句，好比select * from table1; 3.輸入show profiles;看看剛纔那條語句的ID 用於後面分析 4.show profile for query 2; 5.show profile block io,cpu for query 2; 6.show profile cpu,block io,memory,swaps,context switches,source for query 5; 7.經過上面的一些查詢 大致能夠看出這條SQL語句執行的時候哪些地方佔用的時間太大了。此次測試看到的是Copying to tmp table on disk和converting HEAP to MyISAM佔有的時間太多。網上查了一下發現能夠修改一下tmp_table_size和max_heap_table_size兩個參數來調整，使得大數據量的查詢時不用將結果集拷貝到物理磁盤。這樣時間就爭取過來了 對了 MYSQL有個好用的命令能夠分析一條SQL的結構，能夠查到這個查詢是否使用到索引等。直接explain select * from table1就好了 +--------------------------------+------------+------------+------------+-------------------+---------------------+--------------+---------------+-------+---------------------------+---------------+-------------+ | Status | Duration | CPU_user | CPU_system | Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out | Swaps | Source_function | Source_file | Source_line | +--------------------------------+------------+------------+------------+-------------------+---------------------+--------------+---------------+-------+---------------------------+---------------+-------------+ | checking query cache for query | 0.00001100 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | send_result_to_client | sql_cache.cc | 1094 | | Opening tables | 0.00023400 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | open_tables | sql_base.cc | 2106 | | System lock | 0.00002800 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | mysql_lock_tables | lock.cc | 153 | | Table lock | 0.00001300 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | mysql_lock_tables | lock.cc | 162 | | optimizing | 0.00022700 | 0.00099900 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | optimize | sql_select.cc | 617 | | statistics | 0.00002900 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | optimize | sql_select.cc | 773 | | preparing | 0.00012800 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | optimize | sql_select.cc | 783 | | Creating tmp table | 0.00003400 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | optimize | sql_select.cc | 1206 | | executing | 0.00003100 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | exec | sql_select.cc | 1407 | | Copying to tmp table | 0.00001100 | 0.00000000 | 0.00000000 | 0 | 0 | 0 | 0 | 0 | exec | sql_select.cc | 1547 | | converting HEAP to MyISAM | 3.94055900 | 3.81042100 | 0.12498100 | 6 | 7 | 0 | 0 | 0 | create_myisam_from_heap | sql_select.cc | 9914 | | Copying to tmp table on disk | 5.10490400 | 5.00623900 | 0.09798500 | 8 | 10 | 0 | 0 | 0 | create_myisam_from_heap | sql_select.cc | 9968 | | Sending data | 3.09531800 | 2.96954900 | 0.12698100 | 4 | 4 | 0 | 0 | 0 | exec | sql_select.cc | 1925 | | converting HEAP to MyISAM | 1.62242300 | 1.37279100 | 0.25096200 | 38 | 15 | 0 | 0 | 0 | create_myisam_from_heap | sql_select.cc | 9914 | | Sending data | 5.13815600 | 5.04223300 | 0.09698500 | 13 | 10 | 0 | 0 | 0 | create_myisam_from_heap | sql_select.cc | 9968 | | optimizing | 2.17403900 | 2.01069500 | 0.16497500 | 5 | 3 | 0 | 0 | 0 | optimize | sql_select.cc | 617 | mysql官網論壇也有講過這配置 但沒說到第二項配置 http://forums.mysql.com/read.php?22,111012,111012#msg-111012
-————————————————————————————————————————————————————————————————————————————————————————————————————
http://www.mysqlab.net/knowledge/kb/detail/topic/myisam/id/6149php
Discussion
The state "converting HEAP to MyISAM" happens when a query that needs a temporary table is converting from an in-memory temporary table to a disk-based temporary table.mysql
MySQL uses memory-based temporary tables up to the size limit set by the tmp_table_size system variable. If a query needs a temporary table larger than this it will be converted to a disk-based temporary table using the MyISAM storage engine.sql
GROUP BY queries and ORDER BY queries that can't use an index for the ordering are the most common causes of temporary table creation.數據庫
Solution
You could consider raising the per-session value of tmp_table_size if you have sufficient memory. Use the SHOW GLOBAL STATUS statement to see the value of the Created_tmp_tables variable. It will show the total number of temporary tables that have been created:session
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| Created_tmp_tables | 13 |
+--------------------+-------+
Theapp
Created_tmp_disk_tableside
variable shows how many of those have been converted to disk temporary tables:性能
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
+-------------------------+-------+
調2個參數測試
tmp_table_size和max_heap_table_size ============> converting HEAP to MyISAM大數據