แอปพลิเคชันสอบถามตารางที่ว่างเปล่า

บริษัท ของฉันใช้แอปพลิเคชันที่มีปัญหาด้านประสิทธิภาพที่สำคัญ มีปัญหาหลายอย่างเกี่ยวกับฐานข้อมูลของตัวเองซึ่งฉันกำลังอยู่ในขั้นตอนการทำงาน แต่มีปัญหามากมายที่เกี่ยวข้องกับการใช้งานอย่างแท้จริง

ในการตรวจสอบของฉันฉันพบว่ามีล้านแบบสอบถามกดปุ่มฐานข้อมูล SQL Server ซึ่งแบบสอบถามตารางที่ว่างเปล่า เรามีตารางว่างเปล่าประมาณ 300 ตารางและบางตารางมีการสอบถามถึง 100-200 ครั้งต่อนาที ตารางไม่มีส่วนเกี่ยวข้องกับธุรกิจของเราและเป็นส่วนหนึ่งของแอปพลิเคชันดั้งเดิมซึ่งผู้ขายไม่ได้ลบเมื่อ บริษัท ของฉันทำสัญญาเพื่อผลิตโซลูชันซอฟต์แวร์สำหรับเรา

นอกเหนือจากข้อเท็จจริงที่ว่าเราสงสัยว่าบันทึกข้อผิดพลาดแอปพลิเคชันของเรากำลังถูกน้ำท่วมด้วยข้อผิดพลาดที่เกี่ยวข้องกับปัญหานี้ผู้จัดจำหน่ายมั่นใจกับเราว่าไม่มีประสิทธิภาพหรือเสถียรภาพด้านผลกระทบสำหรับทั้งแอปพลิเคชันหรือเซิร์ฟเวอร์ฐานข้อมูล บันทึกข้อผิดพลาดมีน้ำท่วมจนเราไม่สามารถเห็นข้อผิดพลาดเกินกว่า 2 นาทีในการวินิจฉัย

ค่าใช้จ่ายจริงของข้อความค้นหาเหล่านี้เห็นได้ชัดว่าอยู่ในระดับต่ำในแง่ของรอบการทำงานของ CPU เป็นต้น แต่ใครก็ตามสามารถแนะนำสิ่งที่มีผลต่อ SQL Server และแอปพลิเคชันได้บ้าง ฉันสงสัยว่ากลไกที่แท้จริงของการส่งคำขอยืนยันดำเนินการส่งคืนและยอมรับการรับแอปพลิเคชันนั้นจะส่งผลกระทบต่อประสิทธิภาพการทำงาน

เราใช้ SQL Server 2008 R2, Oracle Weblogic 11g สำหรับแอป

@ Frisbee- เรื่องสั้นสั้นฉันสร้างตารางที่มี querytext ซึ่งตีตารางที่ว่างเปล่าในฐานข้อมูลของแอพจากนั้นทำการสอบถามสำหรับ tablenames ทั้งหมดที่ฉันรู้ว่าว่างเปล่าและมีรายการที่ยาวมาก สิ่งที่ฮิตที่สุดคือการประหารชีวิต 2.7 ล้านครั้งในช่วงเวลา 30 วันโดยคำนึงถึงแอปที่ใช้กันทั่วไป 8 โมงเช้าถึงหกโมงเย็นดังนั้นตัวเลขเหล่านี้จึงมีความเข้มข้นมากกว่าเวลาทำการ หลายตารางหลายแบบสอบถามอาจบาง relavent ผ่านการเข้าร่วมบางคนไม่ Hit ที่ได้รับความนิยมสูงสุด (2.7 ล้านในเวลานั้น) เป็นตัวเลือกที่ง่ายจากตารางที่ว่างเปล่าเพียงตารางเดียวโดยไม่มีส่วนร่วม ฉันคาดว่าแบบสอบถามที่มีขนาดใหญ่กว่าด้วยการรวมเข้ากับตารางที่ว่างเปล่าอาจรวมถึงการปรับปรุงไปยังตารางที่เชื่อมโยง แต่ฉันจะตรวจสอบและอัปเดตคำถามนี้โดยเร็ว

อัปเดต: มี 1,000 ข้อความค้นหาที่มีจำนวนการดำเนินการระหว่าง 1043 - 4622614 (มากกว่า 2.5 เดือน) ฉันจะต้องขุดให้มากขึ้นเพื่อดูว่าเมื่อใดที่แผนแคชถูกสร้างขึ้นมา นี่เป็นเพียงเพื่อให้คุณทราบขอบเขตของแบบสอบถาม ส่วนใหญ่มีความซับซ้อนพอสมควรมีผู้เข้าร่วมมากกว่า 20 คน

@ srutzky- ใช่ฉันเชื่อว่ามีคอลัมน์วันที่ที่เกี่ยวข้องกับเมื่อแผนถูกรวบรวมเพื่อให้เป็นที่สนใจดังนั้นฉันจะตรวจสอบว่า ฉันสงสัยว่าการ จำกัด เธรดจะเป็นปัจจัยทั้งหมดเมื่อ SQL Server อยู่ในคลัสเตอร์ VMware หรือไม่ อีกไม่นานจะได้เป็น Dell PE 730xD โดยเฉพาะ

@Frisbee - ขออภัยในความล่าช้า ตามที่คุณแนะนำฉันเลือก * จากตารางว่าง 10,000 ครั้งใน 24 กระทู้โดยใช้ SQLQueryStress (จริง ๆ แล้ว 240,000 ซ้ำ) และกด 10,000 Batch Requests / วินาทีทันที จากนั้นฉันลดเหลือ 1,000 ครั้งใน 24 กระทู้และกดต่ำกว่า 4,000 Batches Requests / วินาที ฉันยังลอง 10,000 ซ้ำใน 12 กระทู้เท่านั้น (รวม 120000 ซ้ำ) และทำให้ 6,505 Batches / วินาทียั่งยืน ผลกระทบที่เกิดขึ้นกับ CPU นั้นสามารถสังเกตเห็นได้จริงประมาณ 5-10% ของการใช้ CPU ทั้งหมดในระหว่างการทดสอบ เครือข่ายที่รอนั้นมีน้อยมาก (เช่น 3ms กับไคลเอนต์บนเวิร์กสเตชันของฉัน) แต่ผลกระทบของ CPU อยู่ที่นั่นแน่นอนซึ่งเป็นข้อสรุปที่สวยตราบใดที่ฉันกังวล ดูเหมือนว่าจะลดลงถึงการใช้งาน CPU และไฟล์ฐานข้อมูลที่ไม่มีความจำเป็น IO การประหารชีวิตโดยรวม / วินาทีนั้นทำได้น้อยกว่า 3000 ซึ่งมากกว่าในการผลิต แต่ฉันทดสอบเพียงหนึ่งในสิบของแบบสอบถามเช่นนี้ ผลสุทธิของการค้นหาหลายร้อยครั้งที่เข้าสู่ตารางที่ว่างเปล่าในอัตราระหว่าง 300-4,000 ครั้งต่อนาทีดังนั้นจะไม่มีผลกระทบเล็กน้อยเมื่อพูดถึงเวลาของ CPU การทดสอบทั้งหมดทำกับ PE 730xD ที่ไม่ได้ใช้งานพร้อมด้วยแฟลชคู่และ RAM ขนาด 256GB, 12 คอร์ที่ทันสมัย

@ srutzky- คิดดี SQLQueryStress ดูเหมือนว่าจะใช้การเชื่อมต่อร่วมกันโดยค่าเริ่มต้น แต่ฉันได้ดูแล้วและพบว่าใช่มีการตรวจสอบกล่องสำหรับการเชื่อมต่อร่วมกัน อัปเดตเพื่อติดตาม

@ srutzky- การเชื่อมต่อร่วมกันนั้นไม่ได้เปิดใช้งานในแอปพลิเคชัน - หรือถ้าเป็นเช่นนั้นมันไม่ทำงาน ฉันติดตาม profiler และพบว่าการเชื่อมต่อมี EventSubClass "1 - Nonpooled" สำหรับเหตุการณ์ Audit Login

RE: Connection Pooling- ตรวจสอบ weblogics และพบว่า pooling การเชื่อมต่อถูกเปิดใช้งาน เรียกใช้ร่องรอยเพิ่มเติมต่อการถ่ายทอดสดและพบว่ามีการรวมกันไม่เกิดขึ้นอย่างถูกต้อง / เลย:

และนี่คือสิ่งที่ดูเหมือนว่าเมื่อฉันเรียกใช้แบบสอบถามเดียวโดยไม่รวมกับตารางที่มีประชากร ข้อยกเว้นอ่าน "เกิดข้อผิดพลาดเกี่ยวกับเครือข่ายหรือเฉพาะของอินสแตนซ์ขณะสร้างการเชื่อมต่อกับ SQL Server ไม่พบเซิร์ฟเวอร์หรือไม่สามารถเข้าถึงได้ตรวจสอบว่าชื่ออินสแตนซ์ถูกต้องและมีการกำหนดค่า SQL Server เพื่ออนุญาตการเชื่อมต่อระยะไกล (ผู้ให้บริการ: เนมไปป์ผู้ให้บริการข้อผิดพลาด: 40 - ไม่สามารถเปิดการเชื่อมต่อกับ SQL Server) "หมายเหตุชุดการร้องขอการนับ ส่ง Ping ไปยังเซิร์ฟเวอร์ในช่วงเวลาที่ข้อยกเว้นถูกสร้างผลลัพธ์ในการตอบสนอง ping ที่ประสบความสำเร็จ

อัพเดต - รันการทดสอบต่อเนื่องสองครั้ง, เวิร์กโหลดเดียวกัน (เลือก * จากEmptyTable), เปิดใช้งานการรวมกำไร / ไม่เปิดใช้งาน การใช้ CPU มากขึ้นเล็กน้อยและความล้มเหลวจำนวนมากและไม่เคยไปเกิน 500 ชุดคำขอ / วินาที การทดสอบแสดง 10,000 Batches / วินาทีและไม่มีความล้มเหลวเมื่อรวมกำไรกันแล้วและประมาณ 400 batches / วินาทีจากนั้นมีความล้มเหลวมากมายเนื่องจากการรวมกำไรถูกปิดใช้งาน ฉันสงสัยว่าความล้มเหลวเหล่านี้เกี่ยวข้องกับการขาดความพร้อมในการเชื่อมต่อหรือไม่?

@ srutzky- เลือกจำนวน (*) จาก sys.dm_exec_connections

• เปิดใช้งานการรวม: 37 อย่างสม่ำเสมอแม้หลังจากหยุดการทดสอบโหลดแล้ว

• การรวมกำไรถูกปิดใช้งาน: 11-37 ขึ้นอยู่กับว่ามีข้อยกเว้น
  เกิดขึ้นบน SQLQueryStress หรือไม่: เมื่อรางเหล่านั้นปรากฏบน
  กราฟ Batches / วินาทีข้อยกเว้นเกิดขึ้นบน SQLQueryStress และ
  จำนวนการเชื่อมต่อลดลงถึง 11 จากนั้นค่อยสำรองสูงสุด 37 เมื่อแบตช์เริ่มขึ้นสู่จุดสูงสุดและข้อยกเว้นจะไม่เกิดขึ้น น่าสนใจมาก ๆ

การเชื่อมต่อสูงสุดทั้งอินสแตนซ์การทดสอบ / อินสแตนซ์ตั้งค่าเริ่มต้นเป็น 0

ตรวจสอบบันทึกของแอปพลิเคชันแล้ว แต่ไม่พบปัญหาการเชื่อมต่ออย่างไรก็ตามมีการบันทึกเพียงไม่กี่นาทีเนื่องจากมีข้อผิดพลาดจำนวนมากและขนาดเช่น: ข้อผิดพลาดในการติดตามสแต็กจำนวนมาก เพื่อนร่วมงานในการสนับสนุนแอปแนะนำว่าข้อผิดพลาด HTTP จำนวนมากเกิดขึ้นที่เกี่ยวข้องกับการเชื่อมต่อ ดูเหมือนว่าจะขึ้นอยู่กับสิ่งนี้ว่าด้วยเหตุผลบางอย่างแอปพลิเคชันที่ไม่ได้รวมการเชื่อมต่ออย่างถูกต้องและด้วยเหตุนี้เซิร์ฟเวอร์จึงขาดการเชื่อมต่อซ้ำ ๆ ฉันจะตรวจสอบบันทึกแอพเพิ่มเติม ฉันสงสัยว่ามีวิธีการพิสูจน์ว่าสิ่งนี้เกิดขึ้นในการผลิตจากฝั่งเซิร์ฟเวอร์ SQL หรือไม่?

@ srutzky- ขอบคุณ ฉันจะตรวจสอบการกำหนดค่าทางเว็บในวันพรุ่งนี้และอัปเดต ฉันคิดว่าเกี่ยวกับการเชื่อมต่อเพียง 37 - ถ้า SQLQueryStress ทำ 12 กระทู้ที่ 10,000 ซ้ำ = 120,000 งบเลือกไม่ใช่สระว่ายน้ำไม่ได้หมายความว่าแต่ละเลือกสร้างการเชื่อมต่อที่แตกต่างกับอินสแตนซ์ SQL?

@ srutzky- Weblogics ได้รับการกำหนดค่าให้เชื่อมต่อกับพูลดังนั้นจึงควรใช้งานได้ดี การรวมการเชื่อมต่อได้รับการกำหนดค่าเช่นนี้ในแต่ละบล็อกการโหลดบาลานซ์ 4 รายการ:

• ความจุเริ่มต้น: 10
• ความจุสูงสุด: 50
• ความจุขั้นต่ำ: 5

เมื่อฉันเพิ่มจำนวนเธรดที่เรียกใช้การเลือกจากคิวรีตารางที่ว่างเปล่าจำนวนการเชื่อมต่อสูงสุดประมาณ 47 เมื่อปิดการรวมการเชื่อมต่อถูกปิดใช้งานฉันเห็นการร้องขอแบตช์สูงสุดต่อวินาทีต่ำลง สิ่งที่จะเกิดขึ้นทุกครั้งคือ 'ข้อยกเว้น' บน SQLQueryStress เกิดขึ้นไม่นานหลังจากที่แบทช์ / วินาทีเข้าสู่รางน้ำ มันเกี่ยวข้องกับการเชื่อมต่อ แต่ฉันไม่สามารถเข้าใจได้อย่างชัดเจนว่าทำไมสิ่งนี้ถึงเกิดขึ้น เมื่อไม่มีการทดสอบใด ๆ #connections จะลดลงเหลือประมาณ 12

เมื่อการรวมการเชื่อมต่อถูกปิดใช้งานฉันมีปัญหาในการทำความเข้าใจว่าทำไมข้อยกเว้นจึงเกิดขึ้น แต่อาจเป็นคำถาม / คำถามแบบสแต็กซ์เอ็กซ์เชนจ์อื่น ๆ สำหรับ Adam Machanic

@ srutzky ฉันสงสัยว่าทำไมข้อยกเว้นเกิดขึ้นโดยไม่เปิดใช้งานการรวมกำไรแม้ว่า SQL Server จะไม่เชื่อมต่อหมด

ฉันสงสัยว่ากลไกที่แท้จริงของการส่งคำขอยืนยันดำเนินการส่งคืนและยอมรับการรับแอปพลิเคชันนั้นจะส่งผลกระทบต่อประสิทธิภาพการทำงาน

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

ที่ถูกกล่าวว่าคุณกำลังถามว่าสิ่งที่อาจเป็นปัญหาและมีบางสิ่งที่จะพูดถึงแม้ว่าบางส่วนของเหล่านี้ไม่ได้เป็นปัจจัยในสถานการณ์เฉพาะของคุณ คุณพูดว่า:

เรามีตารางว่างเปล่าประมาณ 300 ตารางและบางตารางมีการสอบถามถึง 100-200 ครั้งต่อนาที

• ตารางว่างเปล่าที่ไม่ได้ถูกสอบถามไม่มีปัญหา แต่ฉันคิดว่าคุณอาจหมายถึงว่าพวกเขาทั้งหมดถูกสอบถามว่ามีบางคนได้รับผลกระทบมากกว่าคนอื่น ๆ
• การแยกวิเคราะห์ข้อความ & การสร้างแผนปฏิบัติการไม่น่าเป็นปัญหามากนักหากข้อความค้นหาที่ส่งมานั้นยังคงเหมือนเดิมในการโทร SQL Server จะแฮชข้อความของแบบสอบถามและค้นหาในแคชแผน หากพบว่าจะไม่ทำขั้นตอนการแยกวิเคราะห์หรือรวบรวมอีกครั้ง (จนกว่าแผนจะถูกลบออกจากแคช)
• ตารางใด ๆ ที่ว่างเปล่าหรือไม่ว่างจะต้องมีการล็อคอย่างน้อย "ที่ใช้ร่วมกัน" เพื่อระบุว่ากำลังใช้ทรัพยากรอยู่ สิ่งนี้ป้องกันการดำเนินการที่ต้องการการล็อคแบบเอกสิทธิ์ (เพิ่ม / เปลี่ยน / ลบคอลัมน์ ฯลฯ ) จากการเปลี่ยนแปลงในขณะที่ใช้งานทรัพยากร การล็อกและปลดล็อกแม้ว่าจะประสบความสำเร็จในเวลาน้อยกว่า 1 มิลลิวินาทีเนื่องจากไม่มีข้อมูล แต่ก็ยังต้องการทรัพยากรระบบ (หน่วยความจำและ CPU) เพื่อจัดการการล็อคเหล่านั้น
• แม้ว่าจะไม่มีชุดผลลัพธ์ที่กลับมาที่แอพจาก SQL Server แต่ก็ยังมีปริมาณการรับส่งข้อมูลเครือข่ายเท่ากันที่ไปยัง SQL Server ไม่ว่าแบบสอบถามจะให้ผลลัพธ์หรือไม่ก็ตาม ต้องส่งข้อความของแบบสอบถามหรือชื่อของกระบวนงานที่เก็บไว้ และแม้ว่าจะไม่มีผลลัพธ์ใด ๆ กลับมา SQL Server ยังคงต้องส่งแพ็กเก็ตเครือข่ายบางอย่างที่มีโครงสร้างชุดผลลัพธ์เพิ่มเติมจากแพ็คเก็ตที่บอกลูกค้าว่าชุดผลลัพธ์เริ่มต้น (แม้ว่าจะไม่พบแถว) และชุดผลลัพธ์นั้น สิ้นสุดและควรจะปิด และอาจมีข้อความเพิ่มเติมจากคำสั่งพิมพ์และ / หรือจำนวนแถว
• การเชื่อมต่อกับ SQL Server ต้องการทรัพยากรระบบจำนวนหนึ่ง ใช้ CPU และหน่วยความจำในการจัดการการรับรองความถูกต้อง (เช่นเดียวกับแพ็คเก็ตเครือข่ายไปมา) และยังใช้เวลา นี่คือสาเหตุที่ Connection Pooling มีอยู่: เพื่อลดค่าใช้จ่ายนี้
• แม้ว่าจะมีการรวมการเชื่อมต่อที่ลดการใช้ทรัพยากรระบบ แต่ SQL Server ยังคงต้องการรักษาการเชื่อมต่อเหล่านั้นและต้องใช้หน่วยความจำและ CPU ขั้นต่ำ
• แม้จะไม่มีแถวและด้วยเหตุนี้เวลาดำเนินการที่รวดเร็วมากแบบสอบถามก็ยังดำเนินการอยู่ แม้ว่าจะมี 10 หรือ 10,000 แถวและสิ่งเหล่านั้นก็ถูกดึงออกมาจาก Buffer Pool (เช่นหน่วยความจำ) เนื่องจากมันถูกใช้บ่อยเธรดก็ยังต้องใช้งาน และเธรดที่ใช้งานคิวรีที่ไร้ประโยชน์นี้จะไม่ทำงานกับคิวรีที่มีประโยชน์จริง

อาจมีมากกว่านี้อีก แต่สิ่งนี้จะช่วยให้เข้าใจมากขึ้น และโปรดทราบว่าเช่นเดียวกับปัญหาด้านประสิทธิภาพส่วนใหญ่เป็นเรื่องของการปรับขนาด รายการทั้งหมดที่กล่าวมาข้างต้นไม่มีปัญหาหากถูกตีหนึ่งครั้งต่อนาที มันเหมือนกับการทดสอบการเปลี่ยนแปลงในเวิร์กสเตชันของคุณหรือในฐานข้อมูลการพัฒนา: มันทำงานได้กับแถว 10 - 100 แถวเท่านั้น ย้ายรหัสนั้นไปยังการผลิตและใช้เวลา 10 นาทีในการทำงานและมีคนพูดว่า: "ก็ใช้งานได้ในกล่องของฉัน" ;-) ความหมายเป็นเพราะปริมาณการโทรที่แท้จริงทำให้คุณเห็นปัญหา แต่นั่นเป็นสถานการณ์ที่มีอยู่

ดังนั้นแม้จะมี 1 ล้านคิวรี่การสอบถามแถว 0 ที่ไร้ประโยชน์นั่นก็คือ:

• มีการล็อคเพิ่มอีก 2 ล้านครั้ง (ทุกล็อคต้องปลดล็อคใช่ไหม) นี่คือค่าใช้จ่ายส่วนใหญ่ที่ใช้ในการดำเนินการที่ไร้ประโยชน์แทนที่จะเป็นการดำเนินการที่มีประโยชน์
• การรับส่งข้อมูลเครือข่ายเพิ่มเติมที่อาจทำให้คุณใกล้ชิดกับความอิ่มตัวมากขึ้น (ไม่แน่ใจว่าจะเกิดขึ้นได้อย่างไร แต่ยัง)

• มีการเชื่อมต่อมากขึ้นซึ่งใช้หน่วยความจำมากขึ้น คุณมี RAM จริงที่ไม่ได้ใช้เท่าไหร่ หน่วยความจำนั้นจะใช้ดีกว่าสำหรับการเรียกใช้แบบสอบถามและ / หรือแคชแผนแบบสอบถาม กรณีที่เลวร้ายที่สุดคือคุณมีหน่วยความจำกายภาพไม่เพียงพอและ SQL Server ต้องเริ่มใช้หน่วยความจำเสมือน (swap) เนื่องจากช้าลง (ตรวจสอบบันทึกข้อผิดพลาด SQL Server ของคุณเพื่อดูว่าคุณได้รับข้อความเกี่ยวกับหน่วยความจำแบบเพจหรือไม่)

  และในกรณีที่ทุกคนกล่าวถึง "ก็คือการรวมการเชื่อมต่อ" ใช่ว่าจะช่วยลดจำนวนการเชื่อมต่อที่ต้องการได้อย่างแน่นอน แต่ด้วยข้อความค้นหาที่เข้ามาถึง 200 ครั้งต่อนาทีนั่นเป็นกิจกรรมที่เกิดขึ้นพร้อมกันจำนวนมากและการเชื่อมต่อยังคงมีอยู่สำหรับคำขอที่ถูกกฎหมาย ทำSELECT * FROM sys.dm_exec_connections;เพื่อดูจำนวนการเชื่อมต่อที่คุณใช้งานอยู่

• โดยไม่คำนึงถึงสิ่งใดสิ่งนี้ยังคงมีอย่างน้อย 1 ล้านครั้งในแต่ละวันที่เธรดที่อาจทำสิ่งที่มีประโยชน์นั้นไม่สามารถใช้งานได้แทน

ถ้าฉันไม่ถูกต้องเกี่ยวกับสิ่งที่ฉันระบุที่นี่แล้วมันก็ดูเหมือนว่าแม้ว่าในระดับน้อยนี่เป็นประเภทของการโจมตี DDoS บนระบบของคุณเนื่องจากมันท่วมเครือข่ายและ SQL Server ของคุณด้วยคำขอปลอม ป้องกันการร้องขอที่แท้จริงไม่ให้ไปถึง SQL Server หรือกำลังประมวลผลโดย SQL Server

หากตารางได้รับการเข้าชม 100-200 ครั้งต่อนาทีจะมีหน่วยความจำ (หวังว่า) โหลดบนเซิร์ฟเวอร์ต่ำมาก ถ้าคุณไม่มี CPU หรือหน่วยความจำสูงบนเซิร์ฟเวอร์ฐานข้อมูลนี่น่าจะไม่ใช่ปัญหา

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

ฉันทำการทดสอบกับ 100,000 select count (*) บนตารางว่างและมันรันใน 32 วินาทีและมีการสืบค้นผ่านเครือข่าย ดังนั้น 1/3 มิลลิวินาที หากเครือข่ายของคุณมีการโอเวอร์โหลดสิ่งนี้จะไม่ส่งผลกระทบต่อลูกค้า หากคุณมีปัญหาด้านประสิทธิภาพที่สำคัญปัญหาการค้นหาที่ว่างเปล่า 1/3 มิลลิวินาทีเหล่านี้ไม่ใช่สิ่งที่กำลังฆ่าแอป

และสิ่งเหล่านี้อาจเป็นเพียงส่วนหนึ่งของการเข้าร่วมด้านซ้ายที่จับข้อมูลประเภทคงที่บางส่วนไม่ได้เป็นส่วนหนึ่งของแอปพลิเคชันปัจจุบัน อาจถูกผูกมัดกับข้อสงสัยอื่น ๆ ดังนั้นจึงไม่ใช่การเดินทางไปกลับพิเศษ ถ้าใช่มันเลอะเทอะ แต่ก็ไม่ได้ทำให้เกิดการรับส่งข้อมูลมากขึ้น

ดังนั้นกลับไปดูงบจริง คุณเห็นการอัปเดตเพิ่มหรือลบในตารางเหล่านี้หรือไม่

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

โดยทั่วไปในแต่ละแบบสอบถามจะทำตามขั้นตอนต่อไปนี้:

1. คำขอจากแอปพลิเคชัน
2. ฐานข้อมูลแยกวิเคราะห์แบบสอบถาม
3. เอ็นจิ้นฐานข้อมูลตรวจสอบว่าแบบสอบถามนี้ถูกเก็บไว้ใน RAM หรือไม่ ใช้แผนการดำเนินการหากมีอยู่ในหน่วยความจำ
4. ถ้าไม่มีอยู่ใน RAM, เอ็นจิ้นฐานข้อมูลตรวจสอบสถิติที่มีอยู่บนวัตถุในแบบสอบถามและกำหนดแผนการดำเนินการ
5. เรียกใช้แผนการดำเนินการใช้ i / o เพื่อรับข้อมูลจากดิสก์
6. ตอบสนองต่อแอปพลิเคชัน

คำถามจำนวนมากที่คุณกล่าวถึงอาจทำให้เกิดการโหลดเพิ่มเติมในระบบซึ่งมีการใช้งานหนักมาก - การโหลดเพิ่มเติมในการเชื่อมต่อ, CPU, RAM และ I / O