เหตุใด MySQL จึงสร้างตารางชั่วคราวจำนวนมากบนดิสก์


13

ความผิดพลาดในการตั้งค่าใด ๆ อาจนำไปสู่การสร้างตารางชั่วคราวมากเกินไปโดย mysql..mysql tuner แสดง

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%

ตาราง temp ก่อนหน้านี้คือ "ของ 23725 temp tables 38% ถูกสร้างขึ้นบนดิสก์" แต่ฉันเปลี่ยน max_heap และ tmp_table เป็น 200m จาก 16m และลดลงเป็น 30% ..

การกำหนดค่า:

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

ระบบอื่นที่มีการกำหนดค่าเริ่มต้นจะแสดง "จาก 23725 temp tables, 1% ถูกสร้างขึ้นบนดิสก์" ด้วยฐานข้อมูลเดียวกัน

ฉันพยายามเปลี่ยนเป็นค่าเริ่มต้นบนเครื่องที่มีปัญหานี้และยังคงแสดง "ของ 580 temp tables, 16% ถูกสร้างบนดิสก์"

ฉันใช้ Ubuntu 11.4 64 บิตกับ 48 gb ram มีใครแนะนำวิธีแก้ปัญหาได้หรือไม่?

การเปลี่ยนเอ็นจิน db จาก "myisam" เป็น "memory" บนตารางโดยใช้ "group by" จะแก้ไขปัญหานี้หรือไม่? ตามที่อธิบายไว้ที่นี่: http://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/

คำตอบ:


16

mysqltuner ไม่ค่อยให้ข้อมูลที่เป็นประโยชน์ใด ๆ มันใช้สถิติที่ไม่เกี่ยวข้องส่วนใหญ่เกี่ยวกับ "อัตราการเข้าชม" และวางข้อ จำกัด โดยพลการเกี่ยวกับสิ่งที่เป็นจำนวนที่ยอมรับได้ของเครื่องมือที่เป็นที่ยอมรับ หากคุณไม่ประสบปัญหาด้านประสิทธิภาพคุณไม่จำเป็นต้องแก้ไขปัญหาที่เกิดขึ้นกับคุณ ที่ถูกกล่าวว่านี่เป็นข้อมูลพื้นฐานเล็กน้อยเกี่ยวกับตารางชั่วคราว ...

MySQL ใช้เครื่องมือเก็บข้อมูล MEMORY ภายในเพื่อสร้างตารางชั่วคราวโดยนัย บนตารางชั่วคราวดิสก์ใช้เครื่องมือจัดเก็บ MyISAM

ตารางชั่วคราวถูกสร้างขึ้นบนดิสก์เมื่อ:

  • มีฟิลด์ TEXT หรือ BLOB (เนื่องจาก MEMORY ไม่รองรับประเภทเหล่านี้)
  • ขนาดของตารางชั่วคราวโดยนัยที่เกิดขึ้นมีค่าน้อยกว่าtmp_table_sizeหรือmax_heap_table_size
  • หากใช้คอลัมน์ที่มีมากกว่า 512 ไบต์กับ GROUP BY หรือ UNION หรือ ORDER BY

อ่านเอกสาร MySQLในตารางชั่วคราวภายในสำหรับรายละเอียดเพิ่มเติม

คุณสามารถทำอะไรเกี่ยวกับเรื่องนี้? สมมติว่าจริง ๆ แล้วมันแสดงถึงปัญหาด้านประสิทธิภาพ (แทนที่จะรบกวนคุณโดยไม่รู้ตัว):

  • หลีกเลี่ยงฟิลด์ TEXT / BLOB และใช้ฟิลด์ VARCHAR หรือ CHAR ที่เหมาะสมแทนหากเป็นไปได้
  • หาก TEXT / BLOB ไม่สามารถหลีกเลี่ยงได้ให้แยกตารางเหล่านั้นเพื่อแยกตารางที่มีความสัมพันธ์กับคีย์ต่างประเทศและเข้าร่วมเมื่อคุณต้องการเท่านั้น
  • ปฏิบัติต่อคอลัมน์ขนาดใหญ่มากกว่า 512 ไบต์ตามที่คุณต้องการในฟิลด์ TEXT / BLOB ที่กล่าวถึงข้างต้น
  • ตรวจสอบให้แน่ใจว่าข้อความค้นหาของคุณส่งคืนเฉพาะชุดผลลัพธ์ที่คุณต้องการ (เลือกคำสั่ง WHERE ที่เหมาะสมหลีกเลี่ยง SELECT *)
  • หลีกเลี่ยงเคียวรีย่อยและแทนที่ด้วยการรวมโดยเฉพาะอย่างยิ่งหากพวกเขาส่งคืนชุดผลลัพธ์ขนาดใหญ่
  • รีสอร์ทล่าสุด - เพิ่มทั้งสองและtmp_table_size max_heap_table_sizeอย่าทำสิ่งนี้จนกว่าคุณจะพบว่าแบบสอบถามของคุณไม่สามารถปรับให้เหมาะสม

หากคุณกังวลเกี่ยวกับการกำหนดค่า MySQL ของคุณและไม่พอใจกับการตั้งค่าที่มีอยู่ด้วยตัวคุณเองคุณอาจต้องการตรวจสอบตัวช่วยสร้างการกำหนดค่า Perconaเป็นจุดเริ่มต้น

การเปลี่ยนเอ็นจิน db จาก "myisam" เป็น "memory" บนตารางโดยใช้ "group by" จะแก้ไขปัญหานี้หรือไม่? ตามที่อธิบายไว้ที่นี่

ไม่มันจะไม่ทำและจะทำให้โต๊ะของคุณไม่เคยอยู่บนดิสก์ อย่าทำอย่างนี้


+1 แต่เพิ่มว่ามันน้อยกว่าtmp_table_sizeหรือmax_heap_table_size
Derek Downey

คำแนะนำที่ดีที่สุดโดย mysqltuner คือการเปิดใช้งานบันทึกแบบสอบถามช้า มันจะช่วยให้คุณระบุคำสั่งที่ช้าถ้ามี
fat_mike

2

"การใช้งานชั่วคราว" และ "การใช้ filesort" ไม่ใช่จุดสิ้นสุดของโลก!

เลือก ... จัดกลุ่มตาม a, b สั่งซื้อโดย c, d - ต้องการ 1 หรือ 2 "ตารางชั่วคราว"

มีบางครั้งที่ข้อความค้นหาของคุณจะใช้ตารางชั่วคราว ตารางชั่วคราวอาจทำให้การสืบค้นช้าลงด้วยปัจจัยเล็ก ๆ แต่ถ้าแบบสอบถามยัง "เร็วพอ" อย่ากังวลไปเลย

หากแบบสอบถามช้าเกินไป (โดยมีหรือไม่มีตาราง tmp) เรามาพูดถึงกัน โปรดระบุตารางแสดง SHOW ตารางแสดงสถานะและอธิบาย


1
หากคุณมีดัชนีอยู่(a, b, c, d)จะไม่มีตารางชั่วคราว
Yvan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.