MySQL neden diskte bu kadar çok geçici tablo oluşturuyor?

Herhangi bir yapılandırma hatası mysql .. mysql tuner gösterileri tarafından çok fazla geçici tablolar oluşturmak yol açabilir

Current max_heap_table_size = 200 M
Current tmp_table_size = 200 M
Of 17158 temp tables, 30% were created on disk

table_open_cache = 125 tables
table_definition_cache = 256 tables
You have a total of 97 tables
You have 125 open tables.
Current table_cache hit rate is 3%

Daha önce geçici tablo "23725 geçici tablolar diskte% 38 oluşturuldu" oldu ama ben max_heap ve tmp_table 16m 200m olarak değiştirdi ve% 30'a düştü ..

Yapılandırma:

engine myisam 
group_concat_max_len = 32768
key_buffer_size = 3.7 GB,
thread_stack = 256k,
table_cache = 125
query_cache_limit = 1M
query_cache_size = 16M
join_buffer_size = 2.00 M
max_connections = 800

Varsayılan yapılandırmaya sahip başka bir sistem, aynı veritabanıyla "23725 geçici tablodan% 1, diskte oluşturuldu" gösteriyor.

Bu sorunla makinede varsayılan olarak değiştirmeyi denedim ve hala "580 geçici tablolardan% 16'sı diskte oluşturuldu" gösteriyor.

48 gb ram ile Ubuntu 11.4 64 bit kullanıyorum. Birisi çözüm önerisi sunabilir mi?

"Group by" kullanarak tablolarda db altyapısını "myisam" dan "bellek" olarak değiştirecek mi? Burada açıklandığı gibi: http://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/

mysqltuner nadiren yararlı bilgiler sağlar. "İsabet oranları" ile ilgili çoğunlukla alakasız istatistikler kullanır ve kabul edilebilir sayıda widget için kabul edilebilir sınırlar üzerinde keyfi sınırlar koyar. Bir performans sorunuyla karşılaşmıyorsanız, size sunduğu sorunların hiçbirini çözmeniz gerekmez. Bununla birlikte, geçici tablolar hakkında biraz arka plan bilgisi ...

MySQL, örtük geçici tablolar oluşturmak için dahili olarak MEMORY depolama motorunu kullanır. Diskteki geçici tablolarda MyISAM depolama motorunu kullanın.

Aşağıdaki durumlarda disk üzerinde geçici tablolar oluşturulur:

• TEXT veya BLOB alanları var (çünkü MEMORY bu türleri desteklemiyor)
• sonuçtaki örtük geçici tablonun boyutu tmp_table_sizeveyamax_heap_table_size
• 512 bayttan daha büyük bir sütun GROUP BY veya UNION veya ORDER BY ile kullanılırsa

Daha fazla ayrıntı için Dahili Geçici Tablolar üzerindeki MySQL Belgelerini okuyun .

Bununla ilgili ne yapabilirsin? Bunun aslında bir performans sorununu temsil ettiğini varsayarsak (sadece sizi entelektüel olarak rahatsız etmek yerine):

• METİN / BLOB alanlarından kaçının ve bunun yerine mümkünse uygun boyutlu VARCHAR veya CHAR alanlarını kullanın.
• TEXT / BLOB kaçınılmazsa, yabancı anahtar ilişkisi olan tabloları ayırmak için sıralayın ve yalnızca ihtiyacınız olduğunda KATILIN.
• Büyük sütunlara, 512 bayttan fazla, yukarıda belirtilen METİN / BLOB alanlarında olduğu gibi davranın.
• Sorgularınızın yalnızca ihtiyacınız olan sonuç kümesini döndürdüğünden emin olun (uygun şekilde NEREDE yan tümceleri, SELECT * öğesinden kaçının)
• Alt sorgulardan kaçının ve özellikle büyük bir sonuç kümesi döndürürlerse bunları birleştirmelerle değiştirin
• Son çare - her ikisini de kaldırın tmp_table_sizeve max_heap_table_size. Sorgularınızın optimize edilemeyeceğini bulamadıkça bunu yapmayın.

MySQL yapılandırmanızdan endişe ediyorsanız ve mevcut ayarlardan kendiniz rahat değilseniz, Percona Yapılandırma Sihirbazı'nı başlangıç ​​noktası olarak kontrol etmek isteyebilirsiniz .

"Group by" kullanarak tablolarda db altyapısını "myisam" dan "bellek" olarak değiştirecek mi? burada açıklandığı gibi

Hayır, olmayacak ve bunu tablolarınızın diske kalıcı olmayacak şekilde yapacak. Bunu yapma.

"geçici kullanmak" ve "filesort kullanmak" dünyanın sonu değildir!

SELECT ... GRUP İLE A, b SİPARİŞ TARAFı c, d - 1 veya 2 "geçici tablo" gerektirir.

Sorgularınızın geçici tabloları kullanacağı basit zamanlar vardır. Geçici tablolar, bir sorguyu küçük bir faktör yavaşlatabilir. Ancak sorgu hala "yeterince hızlı" ise, endişelenmeyin.

Sorgu çok yavaşsa (tmp tabloları olsun veya olmasın), tartışalım. Lütfen tablo oluştur, tablo durumunu göster ve açıkla.