通過設(shè)置tmp_table_size選項來增加一張臨時表的大小，例如做高級GROUP BY操作生成的臨時表。如果調(diào)高該值，MySQL同時將增加heap表的大小，可達(dá)到提高聯(lián)接查詢速度的效果，建議盡量優(yōu)化查詢，要確保查詢過程中生成的臨時表在內(nèi)存中，避免臨時表過大導(dǎo)致生成基于硬盤的MyISAM表。

mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name　　 | Value　|

+———————————-+———+

| Created_tmp_disk_tables | 21197 |

| Created_tmp_files　　　| 58　　|

| Created_tmp_tables　　| 1771587 |

+——————————–+———–+

每次創(chuàng)建臨時表，Created_tmp_tables增加，如果臨時表大小超過tmp_table_size，則是在磁盤上創(chuàng)建臨時表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服務(wù)創(chuàng)建的臨時文件文件數(shù)，比較理想的配置是：

Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%比如上面的服務(wù)器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝1.20%，應(yīng)該相當(dāng)好了

默認(rèn)為16M，可調(diào)到64-256最佳，線程獨占，太大可能內(nèi)存不夠I/O堵塞

如果動態(tài)頁面要調(diào)大點，100M以上，如果網(wǎng)站大部分都是靜態(tài)內(nèi)容，一般64M足夠。

tmp_table_size優(yōu)化

數(shù)據(jù)庫連接突然增多到1000的問題

查看了一下，未有LOCK操作語句。

但是明顯有好多copy to tmp table的SQL語句，這條語讀的時間比較長，且這個表會被加讀鎖，相關(guān)表的update語句會被排進(jìn)隊列。如果多執(zhí)行幾次這樣的copyt to tmp table 語句，會造成更多的語句被阻塞。
連接太多造成mysql處理慢。

copy to tmp talbe 語句產(chǎn)生的原因是查詢需要Order By 或者Group By等需要用到結(jié)果集時，參數(shù)中設(shè)置的臨時表的大小小于結(jié)果集的大小時，就會將該表放在磁盤上，這個時候在硬盤上的IO要比內(nèi)銷差很多。所耗費的時間也多很多。另外Mysql的另外一個參數(shù)max_heap_table_size比tmp_table_size小時，則系統(tǒng)會把max_heap_table_size的值作為最大的內(nèi)存臨時表的上限，大于這個時，改寫硬盤。
我們的mysql這兩個參數(shù)為：

tmp_table_size 33554432 (33.5M)
max_heap_table_size 16777216 (16.7M)
比較小。
建議增加到上百M。我們的內(nèi)存應(yīng)該夠吧。

另外join_buffer_size（影響 表之間join性能的緩存）為131072 (131K)較小，可以增加一點。

[root@mail ~]# vi /etc/my.cnf

[mysqld]
tmp_table_size=200M

mysql> show processlist;
mysql> show columns from wp_posts;

SQL 語句的第一個 LEFT JOIN ON 子句中： LEFT JOIN _myuser AS t3 ON t1.userid=t3.userid _mydata 的 userid 被參與了條件比較運算。為 _mydata 表根據(jù)字段 userid 建立了一個索引： mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` )  增加 tmp_table_size 值。
mysql 的配置文件中，tmp_table_size 的默認(rèn)大小是 32M。如果一張臨時表超出該大小，MySQL產(chǎn)生一個 The table tbl_name is full 形式的錯誤，如果你做很多高級 GROUP BY 查詢，增加 tmp_table_size 值。 這是 mysql 官方關(guān)于此選項的解釋：

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 等子句中的條件判斷中用到的字段,應(yīng)該根據(jù)其建立索引INDEX。
索引被用來快速找出在一個列上用一特定值的行。沒有索引，MySQL不得不首先以第一條記錄開始并然后讀完整個表直到它找出相關(guān)的行。表越大，花費時間越多。如果表對于查詢的列有一個索引，MySQL能快速到達(dá)一個位置去搜尋到數(shù)據(jù)文件的中間，沒有必要考慮所有數(shù)據(jù)。如果一個表有1000行，這比順序讀取至少快100倍。所有的MySQL索引(PRIMARY、UNIQUE和INDEX)在B樹中存儲。
根據(jù) mysql 的開發(fā)文檔:

索引 index 用于：
快速找出匹配一個WHERE子句的行
當(dāng)執(zhí)行聯(lián)結(jié)(JOIN)時，從其他表檢索行。
對特定的索引列找出MAX()或MIN()值
如果排序或分組在一個可用鍵的最左面前綴上進(jìn)行(例如，ORDER BY key_part_1,key_part_2)，排序或分組一個表。如果所有鍵值部分跟隨DESC，鍵以倒序被讀取。
在一些情況中，一個查詢能被優(yōu)化來檢索值，不用咨詢數(shù)據(jù)文件。如果對某些表的所有使用的列是數(shù)字型的并且構(gòu)成某些鍵的最左面前綴，為了更快，值可以從索引樹被檢索出來。
假定你發(fā)出下列SELECT語句：

mysql> select * FROM tbl_name WHERE col1=val1 AND col2=val2;如果一個多列索引存在于col1和col2上，適當(dāng)?shù)男锌梢灾苯颖蝗〕?。如果分開的單行列索引存在于col1和col2上，優(yōu)化器試圖通過決定哪個索引將找到更少的行并來找出更具限制性的索引并且使用該索引取行。
一般動態(tài)設(shè)置tmp_table_size的大小的時候，要使用:

set global tmp_table_size=64*1024*1024
set global tmp_table_size=64M
#1232 - Incorrect argument type to variable 'tmp_table_size'

最新評論