การนำทาง · ตั้งเป็นหน้าแรก · เพิ่มในรายการโปรด · มือถือ Tencent · หน้าแรกของ Tencent ข่าว บล็อก ฟอรั่ม ความคิดเห็น การเงิน หลักทรัพย์ หุ้นฮ่องกง กองทุน ความบันเทิง ดาว ภาพยนตร์ ดนตรี กีฬา NBA ฟุตบอล รถยนต์ที่ครอบคลุม อสังหาริมทรัพย์ เครื่องใช้ในบ้าน เทคโนโลยี ดิจิตอล ดาวน์โหลดมือถือ อารมณ์ของผู้หญิง การเลี้ยงดู แฟชั่น ช้อปปิ้ง ท่องเที่ยว การอ่าน ต้นฉบับ การศึกษาไปต่างประเทศ เกม อะนิเมะ แอนิเมชั่น กลุ่มดาว วิดีโอ ภาพสด งานเอ็กซ์โป การกุศล เด็ก ๆ แผ่นทองจีนยอดนิยมใหม่ เยี่ยมชมโลกแห่งแฟชั่นและสินค้าหรูหราที่มีสีสัน โทรศัพท์มือถือที่ขายดีที่สุดในประเทศ ติดตามรายการจัดอันดับเพื่อดูว่าคนดังคนไหนมีวันเกิดวันนี้ ตำแหน่งของคุณ: Tencent หน้าแรก > เทคโนโลยีและดิจิทัล > ข่าว Digital Scroll > ข้อความ
Catch-21 สำหรับการพัฒนาฐานข้อมูล SQL Server http://digi.QQ.com 21 ธันวาคม 2552 09:43 Zhongguancun Online หากคุณรับผิดชอบโครงการที่ใช้ SQL Server หรือคุณยังใหม่กับ SQL Server คุณอาจมี กำลังเผชิญกับปัญหาประสิทธิภาพของฐานข้อมูล และบทความนี้จะให้คำแนะนำที่เป็นประโยชน์แก่คุณ (ซึ่งส่วนใหญ่สามารถใช้กับ DBMS อื่น ๆ ได้ด้วย)
ในที่นี้ ฉันจะไม่แนะนำเคล็ดลับในการใช้ SQL Server และไม่สามารถให้วิธีแก้ปัญหาทั้งหมดได้ สิ่งที่ฉันทำคือสรุปประสบการณ์บางประการเกี่ยวกับวิธีสร้างการออกแบบที่ดี ประสบการณ์นี้มาจากสิ่งที่ฉันได้เรียนรู้ในช่วงไม่กี่ปีที่ผ่านมา ซึ่งฉันได้เห็นข้อผิดพลาดในการออกแบบเดิมๆ ซ้ำแล้วซ้ำอีก
1. รู้จักเครื่องมือที่คุณใช้
อย่าดูถูกดูแคลน นี่เป็นจุดสำคัญที่สุดที่ฉันจะทำในบทความนี้ บางทีคุณอาจเห็นแล้วว่าโปรแกรมเมอร์ SQLServer จำนวนมากไม่เข้าใจคำสั่ง T-SQL ทั้งหมดและเครื่องมือที่มีประโยชน์ที่ SQLServer มอบให้
"อะไรนะ? ฉันจะเสียเวลาหนึ่งเดือนในการเรียนรู้คำสั่ง SQL ที่ฉันไม่เคยใช้???" คุณอาจพูดว่า ใช่แล้ว คุณไม่จำเป็นต้องทำเช่นนี้ แต่คุณควรใช้เวลาช่วงสุดสัปดาห์ศึกษาคำสั่ง T-SQL ทั้งหมด งานของคุณที่นี่คือต้องเข้าใจว่าในอนาคต เมื่อคุณออกแบบแบบสอบถาม คุณจะจำได้ว่า: "อย่างไรก็ตาม นี่คือคำสั่งที่สามารถบรรลุฟังก์ชันที่ฉันต้องการได้อย่างเต็มที่" ดังนั้นไปที่ MSDN เพื่อตรวจสอบไวยากรณ์ที่แน่นอนของ คำสั่งนี้
ฉันขอทำซ้ำอีกครั้ง: อย่าใช้เคอร์เซอร์ หากคุณต้องการทำลายประสิทธิภาพของทั้งระบบ สิ่งเหล่านั้นคือตัวเลือกแรกที่มีประสิทธิภาพที่สุดของคุณ ผู้เริ่มต้นส่วนใหญ่ใช้เคอร์เซอร์โดยไม่ได้ตระหนักถึงผลกระทบที่มีต่อประสิทธิภาพการทำงาน พวกมันใช้ความจำ ล็อคโต๊ะด้วยวิธีแปลกๆ และพวกมันทำงานเหมือนหอยทาก และสิ่งที่แย่ที่สุดคือพวกเขาสามารถเพิ่มประสิทธิภาพการทำงานทั้งหมดที่ DBA ของคุณสามารถทำได้เทียบเท่ากับการไม่ทำ คุณรู้ไหมว่าทุกครั้งที่คุณรัน FETCH คุณจะรันคำสั่ง SELECT? ซึ่งหมายความว่าหากเคอร์เซอร์ของคุณมี 10,000 รายการ จะดำเนินการ 10,000 SELECTs! จะมีประสิทธิภาพมากขึ้นหากคุณใช้ชุด SELECT, UPDATE หรือ DELETE เพื่อทำงานที่เกี่ยวข้องให้เสร็จสิ้น
โดยทั่วไปผู้เริ่มต้นคิดว่าการใช้เคอร์เซอร์เป็นวิธีการเขียนโปรแกรมที่คุ้นเคยและสะดวกสบายมากกว่า แต่น่าเสียดายที่การทำเช่นนี้อาจทำให้ประสิทธิภาพไม่ดีได้ แน่นอนว่าวัตถุประสงค์โดยรวมของ SQL คือสิ่งที่คุณต้องการบรรลุ ไม่ใช่อย่างไร
ครั้งหนึ่งฉันเคยเขียนขั้นตอนการจัดเก็บแบบเคอร์เซอร์ใหม่โดยใช้ T-SQL ตารางมีบันทึกเพียง 100,000 รายการ ขั้นตอนการจัดเก็บแบบเดิมใช้เวลาดำเนินการ 40 นาที แต่ขั้นตอนการจัดเก็บใหม่ใช้เวลาเพียง 10 วินาทีเท่านั้น ฉันคิดว่าคุณควรจะได้เห็นว่าโปรแกรมเมอร์ไร้ความสามารถกำลังทำอะไรอยู่! - -
บางครั้งเราสามารถเขียนโปรแกรมขนาดเล็กเพื่อดึงและประมวลผลข้อมูลและอัพเดตฐานข้อมูลซึ่งบางครั้งก็มีประสิทธิภาพมากกว่า ข้อควรจำ: T-SQL ไม่สามารถทำอะไรเกี่ยวกับการวนซ้ำได้
ฉันขอเตือนคุณอีกครั้ง: การใช้เคอร์เซอร์ไม่มีประโยชน์ ฉันไม่เคยเห็นสิ่งใดที่ทำได้อย่างมีประสิทธิภาพโดยใช้เคอร์เซอร์ ยกเว้นงาน DBA
3. สร้างมาตรฐานให้กับตารางข้อมูลของคุณ
ทำไมไม่ทำให้ฐานข้อมูลเป็นมาตรฐาน? อาจมีข้อแก้ตัวสองประการ: เหตุผลด้านประสิทธิภาพและความเกียจคร้านอย่างแท้จริง สำหรับประเด็นที่สองไม่ช้าก็เร็วคุณจะต้องจ่ายเงิน และในเรื่องประสิทธิภาพ คุณไม่จำเป็นต้องปรับแต่งสิ่งที่ไม่ได้ช้าเลย ฉันมักจะเห็นโปรแกรมเมอร์ "ดีนอร์มัลไลซ์" ฐานข้อมูลเพราะเหตุผลก็คือ "การออกแบบดั้งเดิมช้าเกินไป" แต่บ่อยครั้งที่ผลลัพธ์ก็คือพวกเขาทำให้ระบบช้าลง DBMS ได้รับการออกแบบมาเพื่อจัดการฐานข้อมูลรูปแบบมาตรฐาน ดังนั้น โปรดอย่าลืมว่า: ออกแบบฐานข้อมูลตามข้อกำหนดของรูปแบบมาตรฐาน
4. ห้ามใช้ SELECT *
มันไม่ง่ายที่จะทำอย่างที่ฉันรู้ดีเพราะฉันทำเองตลอดเวลา อย่างไรก็ตาม หากคุณระบุคอลัมน์ที่คุณต้องการใน SELECT จะมีประโยชน์ดังต่อไปนี้:
1 ลดการใช้หน่วยความจำและแบนด์วิธเครือข่าย
2 คุณสามารถได้รับการออกแบบที่ปลอดภัยยิ่งขึ้น
3 ให้โอกาสเครื่องมือเพิ่มประสิทธิภาพคิวรีอ่านคอลัมน์ที่จำเป็นทั้งหมดจากดัชนี
หน้า 2: ทำความเข้าใจว่าคุณจะทำอะไรกับข้อมูลของคุณ
การสร้างดัชนีที่แข็งแกร่งสำหรับฐานข้อมูลของคุณเป็นสิ่งที่ดี แต่การทำเช่นนี้เป็นเพียงศิลปะ เมื่อใดก็ตามที่คุณเพิ่มดัชนีลงในตาราง SELECT จะเร็วขึ้น แต่ INSERT และ DELETE จะช้าลงอย่างมาก เนื่องจากการสร้างและดูแลรักษาดัชนีต้องอาศัยการทำงานพิเศษจำนวนมาก แน่นอนว่ากุญแจสำคัญของคำถามนี้คือ: คุณต้องการดำเนินการประเภทใดบนโต๊ะนี้ ปัญหานี้ไม่ใช่เรื่องง่ายที่จะเข้าใจ โดยเฉพาะอย่างยิ่งเมื่อพูดถึง DELETE และ UPDATE เนื่องจากคำสั่งเหล่านี้มักจะมีคำสั่ง SELECT ในส่วน WHERE
6. อย่าสร้างดัชนีในคอลัมน์ "เพศ"
อันดับแรก เราต้องเข้าใจว่าดัชนีเร่งความเร็วในการเข้าถึงตารางได้อย่างไร คุณสามารถนึกถึงดัชนีเป็นวิธีการแบ่งตารางตามเกณฑ์ที่กำหนดได้ หากคุณสร้างดัชนีในคอลัมน์เช่น "เพศ" คุณเพียงแค่แบ่งตารางออกเป็นสองส่วน: ชายและหญิง คุณกำลังจัดการกับตารางที่มี 1,000,000 เรคคอร์ด ความสำคัญของแผนกนี้คืออะไร? ข้อควรจำ: การรักษาดัชนีนั้นใช้เวลานาน เมื่อคุณออกแบบดัชนี โปรดปฏิบัติตามกฎนี้: จัดเรียงคอลัมน์จากมากไปน้อยตามจำนวนเนื้อหาต่างๆ ที่คอลัมน์อาจมี เช่น ชื่อ + จังหวัด + เพศ
7. ใช้ธุรกรรม
โปรดใช้ธุรกรรม โดยเฉพาะอย่างยิ่งเมื่อการสืบค้นใช้เวลานาน หากมีสิ่งผิดปกติเกิดขึ้นกับระบบของคุณ สิ่งนี้จะช่วยชีวิตคุณได้ โดยทั่วไป โปรแกรมเมอร์ที่มีประสบการณ์จะเข้าใจว่าคุณมักจะเผชิญกับสถานการณ์ที่คาดเดาไม่ได้ซึ่งจะทำให้ขั้นตอนการจัดเก็บขัดข้อง
8. ระวังการหยุดชะงัก
เข้าถึงตารางของคุณตามลำดับที่แน่นอน ถ้าคุณล็อกตาราง A ก่อนแล้วจึงล็อกตาราง B จะต้องล็อกตามลำดับนี้ในกระบวนงานที่เก็บไว้ทั้งหมด ถ้าคุณ (โดยบังเอิญ) ล็อกตาราง B ก่อนแล้วจึงล็อกตาราง A ในกระบวนงานเก็บไว้ ซึ่งอาจทำให้เกิดการชะงักงัน หากลำดับการล็อคไม่ได้ออกแบบไว้อย่างละเอียดล่วงหน้า การหยุดชะงักจะตรวจจับได้ยาก
คำถามที่ถามบ่อยคือ ฉันจะเพิ่ม 100,000 ระเบียนลงใน ComboBox ได้อย่างรวดเร็วได้อย่างไร สิ่งนี้ไม่ถูกต้อง และคุณไม่สามารถและไม่จำเป็นต้องทำเช่นนี้ มันง่ายมาก หากผู้ใช้ของคุณต้องเรียกดูบันทึก 100,000 รายการเพื่อค้นหาบันทึกที่เขาต้องการ เขาจะสาปแช่งคุณอย่างแน่นอน ที่นี่ สิ่งที่คุณต้องการคือ UI ที่ดีกว่า และคุณต้องแสดงเรกคอร์ดไม่เกิน 100 หรือ 200 รายการแก่ผู้ใช้ของคุณ
เมื่อเปรียบเทียบกับเคอร์เซอร์ฝั่งเซิร์ฟเวอร์ เคอร์เซอร์ฝั่งไคลเอ็นต์สามารถลดค่าใช้จ่ายของเซิร์ฟเวอร์และเครือข่าย และยังลดเวลาในการล็อคอีกด้วย
11. ใช้แบบสอบถามพารามิเตอร์
บางครั้ง ฉันเห็นคำถามเช่นนี้ในฟอรัมทางเทคนิคของ CSDN: "SELECT * FROM aWHEREa.id='A'B มีข้อยกเว้นเกิดขึ้นเนื่องจากการสอบถามด้วยเครื่องหมายคำพูดเดี่ยว ฉันควรทำอย่างไร" และคำตอบทั่วไปคือ: ใช้สองข้อ เครื่องหมายคำพูดเดี่ยวแทนที่จะเป็นเครื่องหมายคำพูดเดี่ยว นี่เป็นสิ่งที่ผิด วิธีนี้จะปฏิบัติต่ออาการมากกว่าสาเหตุที่แท้จริง เนื่องจากคุณจะพบปัญหาดังกล่าวกับอักขระอื่นๆ และไม่ต้องพูดถึงว่ามันจะทำให้เกิดข้อบกพร่องร้ายแรง นอกจากนี้ ยังจะป้องกันไม่ให้ระบบบัฟเฟอร์ของ SQL Server ทำงานอย่างที่ควรจะเป็น โดยใช้แบบสอบถามพารามิเตอร์ ปัญหาเหล่านี้ทั้งหมดหายไป
12. ใช้ฐานข้อมูลขนาดใหญ่เมื่อเขียนโค้ดโปรแกรม
ฐานข้อมูลทดสอบที่โปรแกรมเมอร์ใช้ในการพัฒนาโดยทั่วไปไม่มีข้อมูลจำนวนมาก แต่บ่อยครั้งที่ผู้ใช้ปลายทางมีข้อมูลจำนวนมาก วิธีการปกติของเรานั้นผิด และเหตุผลก็ง่ายมาก: ตอนนี้ฮาร์ดไดรฟ์ไม่แพงมาก แต่เหตุใดปัญหาด้านประสิทธิภาพจึงไม่สังเกตเห็นจนกว่าจะแก้ไขไม่ได้
13. อย่าใช้ INSERT เพื่อนำเข้าข้อมูลจำนวนมาก
กรุณาอย่าทำเช่นนี้เว้นแต่จะจำเป็นจริงๆ ใช้ UTS หรือ BCP เพื่อให้คุณได้รับความยืดหยุ่นและความเร็วในคราวเดียว
14. ใส่ใจกับปัญหาการหมดเวลา
เมื่อทำการสอบถามฐานข้อมูล ค่าเริ่มต้นของฐานข้อมูลทั่วไปจะค่อนข้างน้อย เช่น 15 วินาทีหรือ 30 วินาที แบบสอบถามบางรายการใช้เวลาทำงานนานกว่านี้ โดยเฉพาะอย่างยิ่งเมื่อปริมาณข้อมูลในฐานข้อมูลยังคงเพิ่มขึ้นอย่างต่อเนื่อง
หน้า 3: อย่ามองข้ามปัญหาในการแก้ไขบันทึกเดียวกันในเวลาเดียวกัน
15. อย่ามองข้ามปัญหาการแก้ไขบันทึกเดิมไปพร้อมๆ กัน
บางครั้ง ผู้ใช้สองคนจะแก้ไขเรกคอร์ดเดียวกันในเวลาเดียวกัน ด้วยวิธีนี้ หากตัวแก้ไขหลังแก้ไขการดำเนินการของตัวแก้ไขก่อนหน้า การอัปเดตบางอย่างจะหายไป การจัดการสถานการณ์นี้ไม่ใช่เรื่องยาก: สร้างฟิลด์ประทับเวลา ตรวจสอบก่อนเขียน รวมการแก้ไขหากได้รับอนุญาต และแจ้งให้ผู้ใช้ทราบหากมีข้อขัดแย้ง
16. เมื่อแทรกบันทึกลงในตารางรายละเอียด ห้ามดำเนินการ SELECT MAX(ID) ในตารางหลัก
นี่เป็นข้อผิดพลาดทั่วไปที่ทำให้เกิดข้อผิดพลาดเมื่อผู้ใช้สองคนแทรกข้อมูลพร้อมกัน คุณสามารถใช้ SCOPE_IDENTITY, IDENT_CURRENT และ IDENTITY หากเป็นไปได้ อย่าใช้ IDENTITY เนื่องจากอาจทำให้เกิดปัญหาเมื่อมีทริกเกอร์ (ดูการสนทนาที่นี่)
17. หลีกเลี่ยงการตั้งค่าคอลัมน์เป็นโมฆะ
หากเป็นไปได้ คุณควรหลีกเลี่ยงการทำให้คอลัมน์เป็นโมฆะ ระบบจะจัดสรรไบต์เพิ่มเติมสำหรับแต่ละแถวของคอลัมน์ NULLable ซึ่งจะทำให้ระบบโอเวอร์เฮดมากขึ้นเมื่อทำการสอบถาม นอกจากนี้ การทำให้คอลัมน์ NULLable มีความซับซ้อนในการเขียนโค้ด เนื่องจากต้องตรวจสอบคอลัมน์เหล่านี้ทุกครั้งที่มีการเข้าถึง
ฉันไม่ได้บอกว่า NULLS เป็นสาเหตุของปัญหา แม้ว่าบางคนจะคิดเช่นนั้นก็ตาม ฉันคิดว่าการสร้างคอลัมน์ NULLable บางครั้งอาจทำงานได้ดีหากคุณอนุญาตให้ใช้ "ข้อมูลว่าง" ในกฎธุรกิจของคุณ แต่การใช้ NULLable ในสถานการณ์เช่นด้านล่างนี้กำลังถามถึงปัญหา
ชื่อลูกค้า1
ที่อยู่ลูกค้า1
อีเมลลูกค้า1
ชื่อลูกค้า2
ที่อยู่ลูกค้า2
อีเมลลูกค้า3
ชื่อลูกค้า1
ที่อยู่ลูกค้า2
อีเมลลูกค้า3
หากสิ่งนี้เกิดขึ้น คุณจะต้องทำให้ตารางของคุณเป็นมาตรฐาน
18. พยายามอย่าใช้ชนิดข้อมูล TEXT
อย่าใช้ TEXT เว้นแต่ว่าคุณกำลังเผชิญกับชุดข้อมูลที่มีขนาดใหญ่มาก เพราะมันไม่ง่ายที่จะสอบถาม ช้า และจะเปลืองพื้นที่มากหากใช้ไม่ถูกต้อง โดยทั่วไป VARCHAR สามารถจัดการข้อมูลของคุณได้ดีขึ้น
19. พยายามอย่าใช้โต๊ะชั่วคราว
พยายามอย่าใช้ตารางชั่วคราว เว้นแต่คุณจะต้องใช้จริงๆ โดยทั่วไป สามารถใช้แบบสอบถามย่อยแทนตารางชั่วคราวได้ การใช้ตารางชั่วคราวจะทำให้ระบบโอเวอร์เฮด และหากคุณเขียนโปรแกรมด้วย COM+ ก็จะเกิดปัญหาตามมามากมาย เนื่องจาก COM+ ใช้พูลการเชื่อมต่อฐานข้อมูลและมีตารางชั่วคราวตั้งแต่ต้นจนจบ SQL Server ให้ทางเลือกบางอย่าง เช่น ชนิดข้อมูลตาราง
20. เรียนรู้การวิเคราะห์และสืบค้น
SQL Server Query Analyzer เป็นเพื่อนที่ดีที่สุดของคุณ ซึ่งคุณสามารถเข้าใจว่าแบบสอบถามและดัชนีส่งผลต่อประสิทธิภาพอย่างไร
21. ใช้ความสมบูรณ์ในการอ้างอิง
การกำหนดคีย์หลัก ข้อจำกัดเฉพาะ และคีย์ต่างประเทศสามารถช่วยประหยัดเวลาได้มาก