mysql tmp_table_size優化之設置多年夜適合。本站提示廣大學習愛好者：（mysql tmp_table_size優化之設置多年夜適合）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql tmp_table_size優化之設置多年夜適合正文
經由過程設置tmp_table_size選項來增長一張暫時表的年夜小，例如做高等GROUP BY操作生成的暫時表。假如調高該值，MySQL同時將增長heap表的年夜小，可到達進步聯接查詢速度的後果，建議盡可能優化查詢，要確保查詢進程中生成的暫時表在內存中，防止暫時表過年夜招致生成基於硬盤的MyISAM表。
mysql> show global status like ‘created_tmp%‘;
+——————————–+———+
| Variable_name | Value |
+———————————-+———+
| Created_tmp_disk_tables | 21197 |
| Created_tmp_files | 58 |
| Created_tmp_tables | 1771587 |
+——————————–+———–+
每次創立暫時表，Created_tmp_tables增長，假如暫時表年夜小跨越tmp_table_size，則是在磁盤上創立暫時表，Created_tmp_disk_tables也增長,Created_tmp_files表現MySQL辦事創立的暫時文件文件數，比擬幻想的設置裝備擺設是：
Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%好比下面的辦事器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝1.20%，應當相當好了
默許為16M，可調到64-256最好，線程獨有，太年夜能夠內存不敷I/O梗塞
假如靜態頁面要調年夜點，100M以上，假如網站年夜部門都是靜態內容，普通64M足夠。
tmp_table_size優化
數據庫銜接忽然增多到1000的成績
檢查了一下，未有LOCK操作語句。
然則顯著有很多多少copy to tmp table的SQL語句，這條語讀的時光比擬長，且這個表會被加讀鎖，相干表的update語句會被排進隊列。假如多履行幾回如許的copyt to tmp table 語句，會形成更多的語句被壅塞。
銜接太多形成mysql處置慢。
copy to tmp talbe 語句發生的緣由是查詢須要Order By 或許Group By等須要用到成果集時，參數中設置的暫時表的年夜小小於成果集的年夜小時，就會將該表放在磁盤上，這個時刻在硬盤上的IO要比外銷差許多。所消耗的時光也多許多。別的Mysql的別的一個參數max_heap_table_size比tmp_table_size小時，則體系會把max_heap_table_size的值作為最年夜的內存暫時表的下限，年夜於這個時，改寫硬盤。
我們的mysql這兩個參數為：
tmp_table_size 33554432 (33.5M)
max_heap_table_size 16777216 (16.7M)
比擬小。
建議增長到上百M。我們的內存應當夠吧。
別的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 表依據字段 userid 樹立了一個索引： mysql> ALTER TABLE `_mydata` ADD INDEX ( `userid` ) 增長 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上，優化器試圖經由過程決議哪一個索引將找到更少的行並來找出更具限制性的索引而且應用該索引取行。
普通靜態設置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'
