將DataTable作為存儲進程參數的用法實例詳解。本站提示廣大學習愛好者：（將DataTable作為存儲進程參數的用法實例詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是將DataTable作為存儲進程參數的用法實例詳解正文
明天在檢討mysql辦事器的時刻提醒Sort aborted: Out of sort memory, consider increasing server sort buffer size，裝置字面意思就是 sort內存溢出，斟酌增長辦事器的排序緩沖區(sort_buffer_size)年夜小
sort_buffer_size=3M
join_buffer_size = 3M
上面是針對16G 內存設置的參數：
sort_buffer_size = 2M
# Sort_Buffer_Size 是一個connection級參數，在每一個connection（session）第一次須要應用這個buffer的時刻，一次性分派設置的內存。
#Sort_Buffer_Size 其實不是越年夜越好，因為是connection級的參數，過年夜的設置+高並發能夠會耗盡體系內存資本。例如：500個銜接將會消費 500*sort_buffer_size(8M)=4G內存
#Sort_Buffer_Size 跨越2KB的時刻，就會應用mmap() 而不是 malloc() 來停止內存分派，招致效力下降。
#技巧導讀 http://blog.webshuo.com/2011/02/16/mysql-sort_buffer_size/
#dev-doc: http://dev.mysql.com/doc/refman/5.5/en/server-parameters.html
#explain select*from table where order limit；湧現filesort
#屬重點優化參數
不外我看到有人將sort_buffer_size設置為10M，我就是由於設置了10M，後來我設置為2-3M，就沒有成績了
Written by cenalulu @ 2010-10-26
基本常識：
1、 Sort_Buffer_Size 是一個connection級參數，在每一個connection第一次須要應用這個buffer的時刻，一次性分派設置的內存。
2、 Sort_Buffer_Size 其實不是越年夜越好，因為是connection級的參數，過年夜的設置+高並發能夠會耗盡體系內存資本。
3、 文檔說“On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation”
本文重要針對第三點做測試：
聽說Sort_Buffer_Size 跨越2KB的時刻，就會應用mmap() 而不是 malloc() 來停止內存分派，招致效力下降。
情況：
為了更年夜的表現機能差距，應用 1GB內存的Fedora 虛擬機停止測試
測試表構造：
1w 行的表， 表構造
+-------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| k | int(10) unsigned | NO | MUL | 0 | |
| c | char(120) | NO | | | |
| pad | char(60) | NO | | | |
+-------+------------------+------+-----+---------+----------------+
測試語句：
分離設置Sort_Buffer_Size 為 250K ，512K， 3M ，然後運轉以下語句，檢查運轉時光。
1. sql_no_cache 避免query cache起效。
2. limit 1 為了削減排序占履行時光的比重，更多的表現內存分派帶來的影響
3. 語句explain的成果是 filesort ， 以確保應用sort_buffer
mysqlslap -uroot -h127.0.0.1 -q ' select sql_no_cache * from sbtest order by pad limit 1' -c 100 --create-schema=test -i 10
測試成果：
履行時光
250K ： 1.318s
512K ： 1.944s
3M ： 2.412s
250 K
[root@localhost tmp]# mysqlslap -uroot -h127.0.0.1 -q ' select sql_no_cache * from sbtest order by pad limit 1' -c 100 --create-schema=test -i 10
Benchmark
Average number of seconds to run all queries: 1.318 seconds
Minimum number of seconds to run all queries: 1.285 seconds
Maximum number of seconds to run all queries: 1.378 seconds
Number of clients running queries: 100
Average number of queries per client: 1
512 K
[root@localhost tmp]# mysqlslap -uroot -h127.0.0.1 -q ' select sql_no_cache * from sbtest order by pad limit 1' -c 100 --create-schema=test -i 10
Benchmark
Average number of seconds to run all queries: 1.944 seconds
Minimum number of seconds to run all queries: 1.362 seconds
Maximum number of seconds to run all queries: 4.406 seconds
Number of clients running queries: 100
Average number of queries per client: 1
3M
[root@localhost tmp]# mysqlslap -uroot -h127.0.0.1 -q ' select sql_no_cache * from sbtest order by pad limit 1' -c 100 --create-schema=test -i 10
Benchmark
Average number of seconds to run all queries: 2.412 seconds
Minimum number of seconds to run all queries: 2.376 seconds
Maximum number of seconds to run all queries: 2.527 seconds
Number of clients running queries: 100
Average number of queries per client: 1
結論：
確切如文檔所說， 應用mmap 分派內存時，會帶來機能上的消耗，影響年夜約在 30% 閣下。
因為是limit 1，是以削弱了buffer size對排序速度的影響。
其實buffer size 越年夜，所須要停止的sort-merge的次數越少，履行時光越短。視詳細的語句而定。
我只是想解釋下，其實不是越年夜越好。 也其實不存在一個相對的最好值。
照樣要看詳細的營業情況決議值的年夜小。 關於高並發的運用，照樣別設置太年夜的比擬好。
