Cấu hình bảng tạm thời MySQL tối ưu (bảng bộ nhớ)?

Question

Trước hết, tôi mới để tối ưu hóa mysql. Thực tế là tôi có trong ứng dụng web của tôi (khoảng 400 truy vấn mỗi giây), một truy vấn sử dụng một GROUP BY mà tôi không thể tránh và đó là nguyên nhân tạo ra các bảng tạm thời. cấu hình của tôi là:

max_heap_table_size = 16M 
tmp_table_size = 32M 

Kết quả: bảng temp vào đĩa trăm + - 12,5%

Sau đó, tôi đã thay đổi các thiết lập của tôi, theo this post

max_heap_table_size = 128M 
tmp_table_size = 128M 

Kết quả: bảng temp vào đĩa phần trăm + - 18%

Kết quả không được mong đợi, không hiểu tại sao.

Đó là sai tmp_table_size = max_heap_table_size? Không nên tăng kích thước?

Query

SELECT images, id 
FROM classifieds_ads 
WHERE parent_category = '1' AND published='1' AND outdated='0' 
GROUP BY aux_order 
ORDER BY date_lastmodified DESC 
LIMIT 0, 100; 

GIẢI THÍCH

| 1 |SIMPLE|classifieds_ads | ref |parent_category, published, combined_parent_oudated_published, oudated | combined_parent_oudated_published | 7 | const,const,const | 67552 | Using where; Using temporary; Using filesort | 

Answer 1

"Sử dụng tạm thời" trong báo cáo giải thích không cho chúng tôi biết rằng bảng temp là trên đĩa. Nó chỉ cho chúng ta biết rằng truy vấn hy vọng sẽ tạo ra một bảng tạm thời.

Bảng tạm thời sẽ ở lại trong bộ nhớ nếu kích thước của nó nhỏ hơn tmp_table_size và nhỏ hơn max_heap_table_size.

Max_heap_table_size là bảng lớn nhất có thể trong bộ nhớ lưu trữ MEMORY, cho dù bảng đó là bảng tạm thời hay bảng tạm thời.

Tmp_table_size là bảng lớn nhất có thể có trong bộ nhớ khi nó được tạo tự động bởi truy vấn. Tuy nhiên, điều này không thể lớn hơn max_heap_table_size. Vì vậy, không có lợi ích để thiết lập tmp_table_size lớn hơn max_heap_table_size. Thông thường, hãy đặt hai biến cấu hình này thành cùng một giá trị.

Bạn có thể theo dõi có bao nhiêu bảng tạm thời được tạo ra, và bao nhiêu trên đĩa như thế này:

mysql> show global status like 'Created%'; 
+-------------------------+-------+ 
| Variable_name   | Value | 
+-------------------------+-------+ 
| Created_tmp_disk_tables | 20 | 
| Created_tmp_files  | 6  | 
| Created_tmp_tables  | 43 | 
+-------------------------+-------+ 

Lưu ý trong ví dụ này, 43 bảng tạm thời được tạo ra, nhưng chỉ có 20 trong số đó là trên đĩa.

Khi bạn tăng giới hạn tmp_table_size và max_heap_table_size, bạn cho phép các bảng tạm thời lớn hơn tồn tại trong bộ nhớ.

Bạn có thể hỏi, bạn cần phải tạo bao nhiêu? Bạn không nhất thiết cần phải làm cho nó đủ lớn cho mỗi bảng tạm thời để phù hợp với bộ nhớ. Bạn có thể muốn 95% bảng tạm thời của bạn phù hợp với bộ nhớ và chỉ còn lại các bảng hiếm còn lại trên đĩa. 5% cuối cùng có thể rất lớn - lớn hơn rất nhiều so với số lượng bộ nhớ bạn muốn sử dụng cho điều đó.

Vì vậy, thực hành của tôi là tăng tmp_table_size và max_heap_table_size một cách thận trọng. Sau đó, xem tỷ lệ của Created_tmp_disk_tables thành Created_tmp_tables để xem liệu tôi có đạt được mục tiêu làm cho 95% trong số chúng nằm trong bộ nhớ hay không (bất kỳ tỷ lệ nào tôi muốn xem).

Thật không may, MySQL không có cách nào tốt để cho bạn biết chính xác mức độ lớn của các bảng tạm thời. Điều đó sẽ thay đổi theo truy vấn, do đó, các biến trạng thái không thể hiển thị điều đó, chúng chỉ có thể cho bạn biết số lần nó đã xảy ra. Và EXPLAIN không thực sự thực hiện truy vấn để nó không thể dự đoán chính xác số lượng dữ liệu sẽ khớp.

Phương án thay thế là Percona Server, là bản phân phối MySQL với các cải tiến. Một trong số này là log extra information in the slow-query log. Bao gồm trong các trường bổ sung là kích thước của bất kỳ bảng tạm nào được tạo bởi một truy vấn đã cho.