เทคนิคการปรับแต่งประสิทธิภาพที่ชื่นชอบ [ปิด]

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

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

ตัวอย่างเช่น SQL Server มาพร้อมกับโฮสต์ของการตรวจสอบประสิทธิภาพ / การปรับแต่งบิต แต่ถ้าคุณไม่มีอะไรเช่นนั้น (และอาจถึงแม้ว่าคุณจะทำ) ฉันจะพิจารณาสิ่งต่อไปนี้ ...

99% ของปัญหาฉันได้เห็นจะเกิดจากการวางตารางมากเกินไปในการเข้าร่วม การแก้ไขสำหรับสิ่งนี้คือทำการรวมครึ่งหนึ่ง (กับบางตาราง) และแคชผลลัพธ์ในตารางชั่วคราว จากนั้นทำส่วนที่เหลือของแบบสอบถามเข้าร่วมในตารางชั่วคราวนั้น

รายการตรวจสอบการเพิ่มประสิทธิภาพการสืบค้น

• เรียกใช้ UPDATE STATISTICS บนตารางพื้นฐาน
  • ระบบจำนวนมากเรียกใช้สิ่งนี้เป็นงานประจำสัปดาห์ตามกำหนดการ
• ลบบันทึกจากตารางพื้นฐาน (อาจเก็บบันทึกที่ลบไปแล้ว)
  • ลองทำโดยอัตโนมัติวันละครั้งหรือสัปดาห์ละครั้ง
• สร้างดัชนีใหม่
• สร้างตารางใหม่ (ข้อมูล bcp ออก / เข้า)
• การถ่ายโอนข้อมูล / โหลดฐานข้อมูลซ้ำ (รุนแรง แต่อาจแก้ไขความเสียหายได้)
• สร้างดัชนีใหม่ที่เหมาะสมกว่า
• เรียกใช้ DBCC เพื่อดูว่ามีความเสียหายในฐานข้อมูลหรือไม่
• ล็อค / การหยุดชะงัก
  • ตรวจสอบให้แน่ใจว่าไม่มีกระบวนการอื่น ๆ ที่ทำงานในฐานข้อมูล
    • โดยเฉพาะ DBCC
  • คุณใช้การล็อกระดับแถวหรือหน้าหรือไม่?
  • ล็อกตารางโดยเฉพาะก่อนเริ่มการสืบค้น
  • ตรวจสอบว่ากระบวนการทั้งหมดกำลังเข้าถึงตารางในลำดับเดียวกัน
• มีการใช้ดัชนีอย่างเหมาะสมหรือไม่?
  • การเข้าร่วมจะใช้ดัชนีก็ต่อเมื่อนิพจน์ทั้งสองเป็นชนิดข้อมูลเดียวกัน
  • ดัชนีจะถูกใช้ก็ต่อเมื่อฟิลด์แรกในดัชนีตรงกับคำค้นหา
  • ดัชนีคลัสเตอร์ถูกใช้ตามความเหมาะสมหรือไม่
    • ข้อมูลช่วง
    • ฟิลด์ WHERE ระหว่างค่า 1 และค่า 2
• การเข้าร่วมขนาดเล็กเป็นการเข้าร่วมที่ดี
  • โดยค่าเริ่มต้นเครื่องมือเพิ่มประสิทธิภาพจะพิจารณาตารางครั้งละ 4 ตารางเท่านั้น
  • ซึ่งหมายความว่าเมื่อรวมกับตารางมากกว่า 4 ตารางจะมีโอกาสที่ดีในการเลือกแผนการสืบค้นข้อมูลที่ไม่เหมาะสม
• เลิกเข้าร่วม
  • คุณสามารถแยกการเข้าร่วมได้หรือไม่?
  • เลือกคีย์ต่างประเทศล่วงหน้าลงในตารางชั่วคราว
  • ทำการรวมครึ่งหนึ่งและใส่ผลลัพธ์ในตารางชั่วคราว
• คุณใช้ตารางชั่วคราวถูกประเภทหรือไม่?
  • #tempตารางอาจทำงานได้ดีกว่า@tableตัวแปรที่มีปริมาณมาก (หลายพันแถว)
• ดูแลตารางสรุป
  • สร้างด้วยทริกเกอร์บนตารางพื้นฐาน
  • สร้างรายวัน / รายชั่วโมง / ฯลฯ
  • สร้างเฉพาะกิจ
  • สร้างเพิ่มขึ้นหรือฉีกขาด / สร้างใหม่
• ดูว่าแผนการค้นหาคืออะไรเมื่อเปิดใช้งาน SET SHOWPLAN
• ดูว่าเกิดอะไรขึ้นจริงกับ SET STATS IO ON
• บังคับดัชนีโดยใช้ pragma: (index: myindex)
• บังคับคำสั่งตารางโดยใช้ SET FORCEPLAN ON
• พารามิเตอร์การดมกลิ่น:
  • แบ่งขั้นตอนที่เก็บไว้เป็น 2
  • โทร proc2 จาก proc1
  • อนุญาตให้เครื่องมือเพิ่มประสิทธิภาพเลือกดัชนีใน proc2 หาก @parameter ถูกเปลี่ยนโดย proc1
• คุณสามารถปรับปรุงฮาร์ดแวร์ของคุณได้หรือไม่?
• คุณวิ่งกี่โมง? มีเวลาที่เงียบกว่านี้หรือไม่?
• Replication Server (หรือกระบวนการ non-stop อื่น ๆ ) กำลังทำงานอยู่หรือไม่ คุณสามารถระงับได้หรือไม่? เรียกใช้เช่น รายชั่วโมงได้อย่างไร

1. มีความคิดที่ดีเกี่ยวกับเส้นทางที่ดีที่สุดในการเรียกใช้แบบสอบถามในหัวของคุณ
2. ตรวจสอบแผนการสืบค้น - เสมอ
3. เปิดใช้งาน STATS เพื่อให้คุณตรวจสอบประสิทธิภาพของ IO และ CPU ได้ มุ่งเน้นไปที่การผลักดันตัวเลขเหล่านั้นให้ต่ำลงไม่จำเป็นต้องเป็นเวลาในการสืบค้น (เนื่องจากอาจได้รับอิทธิพลจากกิจกรรมอื่น ๆ แคช ฯลฯ )
4. มองหาแถวจำนวนมากที่เข้ามาในโอเปอเรเตอร์ แต่มีจำนวนน้อย โดยปกติดัชนีจะช่วยได้โดย จำกัด จำนวนแถวที่เข้ามา (ซึ่งบันทึกการอ่านดิสก์)
5. มุ่งเน้นไปที่แผนผังย่อยที่มีต้นทุนมากที่สุดก่อน การเปลี่ยนแผนผังย่อยนั้นมักจะเปลี่ยนแผนการสืบค้นข้อมูลทั้งหมดได้
6. ปัญหาทั่วไปที่ฉันพบคือ:
   • หากมีการรวมจำนวนมากบางครั้ง Sql Server จะเลือกที่จะขยายการรวมจากนั้นจึงใช้คำสั่ง WHERE โดยปกติคุณสามารถแก้ไขปัญหานี้ได้โดยการย้ายเงื่อนไข WHERE ไปยังส่วนคำสั่ง JOIN หรือตารางที่ได้รับโดยมีเงื่อนไขอยู่ในบรรทัด มุมมองอาจทำให้เกิดปัญหาเดียวกัน
   • การรวม Suboptimal (LOOP vs HASH vs MERGE) หลักการทั่วไปของฉันคือใช้การเข้าร่วม LOOP เมื่อแถวบนสุดมีแถวน้อยมากเมื่อเทียบกับด้านล่างการผสานรวมเมื่อชุดมีค่าเท่ากันและเรียงลำดับและ HASH สำหรับสิ่งอื่น ๆ การเพิ่มคำใบ้เข้าร่วมจะช่วยให้คุณทดสอบทฤษฎีของคุณได้
   • การดมกลิ่นพารามิเตอร์ หากคุณรัน proc ที่จัดเก็บไว้ด้วยค่าที่ไม่สมจริงในตอนแรก (เช่นสำหรับการทดสอบ) แผนเคียวรีแคชอาจไม่เหมาะสมสำหรับค่าการผลิตของคุณ การรันอีกครั้งด้วย RECOMPILE ควรตรวจสอบสิ่งนี้ สำหรับ procs ที่จัดเก็บไว้บางส่วนโดยเฉพาะอย่างยิ่งที่จัดการกับช่วงขนาดที่แตกต่างกัน (เช่นวันที่ทั้งหมดระหว่างวันนี้ถึงเมื่อวาน - ซึ่งจะทำให้เกิด INDEX SEEK หรือวันที่ทั้งหมดระหว่างปีที่แล้วและปีนี้ซึ่งจะดีกว่าเมื่อใช้ INDEX SCAN ) คุณอาจต้องเรียกใช้ด้วย RECOMPILE ทุกครั้ง
   • การเยื้องไม่ถูกต้อง ... เอาล่ะ Sql Server ไม่มีปัญหากับสิ่งนี้ - แต่ฉันแน่ใจว่ามันเป็นไปไม่ได้ที่จะเข้าใจแบบสอบถามจนกว่าฉันจะแก้ไขการจัดรูปแบบ

นอกเรื่องเล็กน้อย แต่ถ้าคุณสามารถควบคุมปัญหาเหล่านี้ได้ ...
ระดับสูงและผลกระทบสูง

• สำหรับสภาพแวดล้อม IO สูงตรวจสอบให้แน่ใจว่าดิสก์ของคุณใช้สำหรับ RAID 10 หรือ RAID 0 + 1 หรือการใช้งานแบบซ้อนกันของ raid 1 และ raid 0
• อย่าใช้ไดรฟ์ที่ต่ำกว่า 1,500K
• ตรวจสอบให้แน่ใจว่าดิสก์ของคุณใช้สำหรับฐานข้อมูลของคุณเท่านั้น IE ไม่มีการบันทึกไม่มี OS
• ปิดการเติบโตอัตโนมัติหรือคุณลักษณะที่คล้ายกัน ให้ฐานข้อมูลใช้ที่เก็บข้อมูลทั้งหมดที่คาดการณ์ไว้ ไม่จำเป็นต้องเป็นสิ่งที่กำลังใช้อยู่
• ออกแบบสคีมาและดัชนีของคุณสำหรับการสืบค้นประเภท
• หากเป็นตารางประเภทบันทึก (แทรกเท่านั้น) และต้องอยู่ในฐานข้อมูลอย่าทำดัชนี
• หากคุณทำการรายงานแบบจัดสรร (เลือกแบบซับซ้อนที่มีการรวมจำนวนมาก) คุณควรดูที่การสร้างคลังข้อมูลด้วยสคีมารูปดาวหรือเกล็ดหิมะ
• อย่ากลัวการจำลองข้อมูลเพื่อแลกกับประสิทธิภาพ!

CREATE INDEX

ตรวจสอบให้แน่ใจว่ามีดัชนีสำหรับคุณWHEREและJOINข้อ ซึ่งจะช่วยเพิ่มความเร็วในการเข้าถึงข้อมูลอย่างมาก

หากสภาพแวดล้อมของคุณเป็นดาต้ามาร์ทหรือคลังสินค้าดัชนีควรมีอยู่มากมายสำหรับแบบสอบถามที่เป็นไปได้เกือบทั้งหมด

ในสภาพแวดล้อมการทำธุรกรรมจำนวนดัชนีควรต่ำกว่าและคำจำกัดความของดัชนีเหล่านี้มีกลยุทธ์มากขึ้นเพื่อให้การบำรุงรักษาดัชนีไม่ลากทรัพยากรลง (การบำรุงรักษาดัชนีคือเมื่อต้องเปลี่ยนใบของดัชนีเพื่อสะท้อนการเปลี่ยนแปลงในตารางพื้นฐานเช่นเดียวกับINSERT, UPDATE,และDELETEการดำเนินงาน)

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

SELECT   i.make, i.model, i.price
FROM     dbo.inventory i
WHERE    i.color = 'red'
  AND    i.price BETWEEN 15000 AND 18000

ราคาโดยทั่วไปมีความสำคัญสูงกว่า อาจมีสีให้เลือกเพียงไม่กี่สี แต่อาจมีราคาที่แตกต่างกันหลายพันราคา

จากตัวเลือกดัชนีเหล่านี้idx01ให้เส้นทางที่เร็วกว่าเพื่อตอบสนองแบบสอบถาม:

CREATE INDEX idx01 ON dbo.inventory (price, color)
CREATE INDEX idx02 ON dbo.inventory (color, price)

เนื่องจากรถยนต์จำนวนน้อยกว่าจะตอบสนองราคาได้มากกว่าการเลือกสีทำให้เครื่องมือสืบค้นข้อมูลในการวิเคราะห์น้อยกว่ามาก

ฉันเป็นที่ทราบกันดีว่ามีดัชนีที่คล้ายกันสองดัชนีที่แตกต่างกันเฉพาะในฟิลด์เพื่อเร่งความเร็วในการสืบค้น (ชื่อนามสกุล) ในหนึ่งและ (นามสกุล, ชื่อ) ในอีกดัชนี

เคล็ดลับที่เพิ่งเรียนรู้คือ SQL Server สามารถอัปเดตตัวแปรภายในและฟิลด์ในคำสั่งอัพเดต

UPDATE table
SET @variable = column = @variable + otherColumn

หรือรุ่นที่อ่านได้มากขึ้น:

UPDATE table
SET
    @variable = @variable + otherColumn,
    column = @variable

ฉันใช้สิ่งนี้เพื่อแทนที่เคอร์เซอร์ / การรวมที่ซับซ้อนเมื่อใช้การคำนวณแบบวนซ้ำและยังได้รับประสิทธิภาพมากมาย

นี่คือรายละเอียดและตัวอย่างโค้ดที่ปรับปรุงประสิทธิภาพได้อย่างยอดเยี่ยม: http://geekswithblogs.net/Rhames/archive/2008/10/28/calculating-running-totals-in-sql-server-2005---the-optimal aspx

สมมติว่า MySQL ที่นี่ใช้ EXPLAIN เพื่อค้นหาว่าเกิดอะไรขึ้นกับแบบสอบถามตรวจสอบให้แน่ใจว่าดัชนีถูกใช้อย่างมีประสิทธิภาพที่สุดเท่าที่จะเป็นไปได้และพยายามกำจัดประเภทไฟล์ High Performance MySQL: การเพิ่มประสิทธิภาพการสำรองข้อมูล, การจำลอง, และอื่น ๆเป็นหนังสือที่ดีในหัวข้อนี้เป็นบล็อก MySQL ผลการดำเนินงาน

@Terrapin มีความแตกต่างอื่น ๆ อีกเล็กน้อยระหว่าง isnull และ coalesce ที่ควรค่าแก่การกล่าวถึง (นอกเหนือจากการปฏิบัติตามข้อกำหนดของ ANSI ซึ่งเป็นเรื่องใหญ่สำหรับฉัน)

Coalesce กับ IsNull

บางครั้งใน SQL Server ถ้าคุณใช้ OR ในส่วนคำสั่งที่มันจะแจ็คด้วยประสิทธิภาพจริงๆ แทนที่จะใช้ OR เพียงเลือกสองรายการแล้วรวมเข้าด้วยกัน คุณจะได้ผลลัพธ์เดียวกันที่ความเร็ว 1,000 เท่า

ดูที่คำสั่ง - ตรวจสอบการใช้ดัชนี / ตรวจสอบว่าไม่มีการทำอะไรโง่ ๆ

where SomeComplicatedFunctionOf(table.Column) = @param --silly

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

ในตารางชั่วคราวทั้งหมดของฉันฉันต้องการเพิ่มข้อ จำกัด เฉพาะ (ตามความเหมาะสม) เพื่อสร้างดัชนีและคีย์หลัก (เกือบตลอดเวลา)

declare @temp table(
    RowID int not null identity(1,1) primary key,
    SomeUniqueColumn varchar(25) not null,
    SomeNotUniqueColumn varchar(50) null,
    unique(SomeUniqueColumn)
)

ฉันได้สร้างนิสัยที่จะใช้ตัวแปรการผูกเสมอ เป็นไปได้ว่าตัวแปรการผูกจะไม่ช่วยหาก RDBMS ไม่แคชคำสั่ง SQL แต่ถ้าคุณไม่ใช้ตัวแปรการผูก RDBMS จะไม่มีโอกาสนำแผนการดำเนินการสืบค้นกลับมาใช้ใหม่และคำสั่ง SQL ที่แยกวิเคราะห์ เงินฝากออมทรัพย์ได้อย่างมหาศาล: http://www.akadia.com/services/ora_bind_variables.html ฉันทำงานกับ Oracle เป็นส่วนใหญ่ แต่ Microsoft SQL Server ทำงานในลักษณะเดียวกัน

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

หลังจากนั้นฉันคุยกับ DBA ของเราเพื่อค้นหาว่าอะไรทำให้ RDBMS เจ็บปวดมากที่สุด โปรดทราบว่าคุณไม่ควรถามว่า "เหตุใดข้อความค้นหานี้จึงช้า" นั่นเหมือนกับการขอให้แพทย์นำไส้ติ่งออก แน่ใจว่าคำถามของคุณอาจมีปัญหา แต่ก็เป็นไปได้ว่ามีข้อผิดพลาดเกิดขึ้น ในฐานะนักพัฒนาเรามักจะคิดในแง่ของบรรทัดของโค้ด ถ้าเส้นช้าให้แก้ไขเส้นนั้น แต่ RDBMS เป็นระบบที่ซับซ้อนมากและการสืบค้นที่ช้าของคุณอาจเป็นอาการของปัญหาที่ใหญ่กว่ามาก

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

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

ขั้นตอนแรก: ดูแผนการดำเนินการสืบค้น!
TableScan ->
NestedLoop ที่ไม่ดี-> คำเตือน Meh
TableScan ที่อยู่เบื้องหลัง NestedLoop -> DOOM!

ตั้งค่าสถิติ IO ใน
เวลาที่ตั้งค่าสถิติ

การเรียกใช้แบบสอบถามโดยใช้ C (NoLock) เป็นการดำเนินการมาตรฐานในสถานที่ของฉัน ใครก็ตามที่พบว่ามีการสืบค้นบนตารางหลายสิบกิกะไบต์โดยที่ไม่ถูกนำออกมาและถูกยิง

แปลงคำค้นหา NOT IN เป็น LEFT OUTER JOINS ถ้าเป็นไปได้ ตัวอย่างเช่นหากคุณต้องการค้นหาแถวทั้งหมดใน Table1 ที่ไม่มีการใช้งานโดย Foreign Key ใน Table2 คุณสามารถทำได้:

SELECT *
FROM Table1
WHERE Table1.ID NOT IN (
    SELECT Table1ID
    FROM Table2)

แต่คุณจะได้รับประสิทธิภาพที่ดีขึ้นมากด้วยสิ่งนี้:

SELECT Table1.*
FROM Table1
LEFT OUTER JOIN Table2 ON Table1.ID = Table2.Table1ID
WHERE Table2.ID is null

@ DavidM

สมมติว่า MySQL ที่นี่ใช้ EXPLAIN เพื่อค้นหาว่าเกิดอะไรขึ้นกับแบบสอบถามตรวจสอบให้แน่ใจว่าดัชนีถูกใช้อย่างมีประสิทธิภาพที่สุด ...

ใน SQL Server แผนการดำเนินการทำให้คุณได้รับสิ่งเดียวกัน - จะบอกคุณว่าดัชนีใดที่ถูกตีเป็นต้น

จัดทำดัชนีตารางตาม clm (s) ที่คุณกรองด้วย

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

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

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

ฉันมองหา:

• คลาย CURSOR ลูปใด ๆ และแปลงเป็นชุดคำสั่ง UPDATE / INSERT
• มองหารหัสแอปพลิเคชันที่:
  • เรียก SP ที่ส่งคืนชุดระเบียนขนาดใหญ่
  • จากนั้นในแอปพลิเคชันให้ดำเนินการตามแต่ละระเบียนและเรียกใช้ SP พร้อมพารามิเตอร์เพื่ออัปเดตระเบียน
  • แปลงสิ่งนี้เป็น SP ที่ทำงานทั้งหมดในธุรกรรมเดียว
• SP ใด ๆ ที่มีการจัดการสตริงจำนวนมาก เป็นหลักฐานว่าข้อมูลไม่มีโครงสร้างที่ถูกต้อง / ทำให้เป็นมาตรฐาน
• SP ใด ๆ ที่ประดิษฐ์วงล้อขึ้นมาใหม่
• SP ใด ๆ ที่ฉันไม่เข้าใจว่ามันพยายามทำอะไรภายในหนึ่งนาที!

SET NOCOUNT ON

@@ROWCOUNTโดยปกติบรรทัดแรกภายในวิธีการจัดเก็บของฉันเว้นแต่ที่จริงผมจำเป็นต้องใช้

ใน SQL Server ให้ใช้คำสั่ง nolock ช่วยให้คำสั่ง select เสร็จสมบูรณ์โดยไม่ต้องรอ - โดยปกติแล้วธุรกรรมอื่น ๆ จะเสร็จ

SELECT * FROM Orders (nolock) where UserName = 'momma'

ลบเคอร์เซอร์ออกจากที่ใดก็ตามที่ไม่จำเป็น

ลบการเรียกฟังก์ชันใน Sprocs ซึ่งแถวจำนวนมากจะเรียกใช้ฟังก์ชัน

เพื่อนร่วมงานของฉันใช้การเรียกฟังก์ชัน (รับ lastlogindate จาก userid เป็นตัวอย่าง) เพื่อส่งคืนชุดระเบียนที่กว้างมาก

ได้รับมอบหมายให้เพิ่มประสิทธิภาพฉันแทนที่การเรียกฟังก์ชันใน sproc ด้วยรหัสของฟังก์ชัน: ฉันมีเวลาในการทำงานของ sprocs ลดลงจาก> 20 วินาทีเป็น <1

• นำหน้าตารางทั้งหมดด้วย dbo เพื่อป้องกันการคอมไพล์ซ้ำ
• ดูแผนการค้นหาและค้นหาการสแกนตาราง / ดัชนี
• ในปี 2548 ตรวจสอบมุมมองของฝ่ายบริหารเพื่อหาดัชนีที่ขาดหายไป

ฉันชอบที่จะใช้

isnull(SomeColThatMayBeNull, '')

เกิน

coalesce(SomeColThatMayBeNull, '')

เมื่อฉันไม่ต้องการการสนับสนุนหลายอาร์กิวเมนต์ที่รวมกันให้คุณ

http://blog.falafel.com/2006/04/05/SQLServerArcanaISNULLVsCOALESCE.aspx

อย่านำหน้าชื่อกระบวนงานที่เก็บไว้ด้วย "sp_" เนื่องจากโพรซีเดอร์ของระบบทั้งหมดขึ้นต้นด้วย "sp_" และ SQL Server จะต้องค้นหายากขึ้นเพื่อค้นหาโพรซีเดอร์ของคุณเมื่อถูกเรียก

อ่านสกปรก -

set transaction isolation level read uncommitted

ป้องกันการล็อกที่ตายโดยที่ความสมบูรณ์ของธุรกรรมไม่จำเป็นอย่างยิ่ง (ซึ่งโดยปกติจะเป็นจริง)

ฉันมักจะไปที่ SQL Profiler (หากเป็นโพรซีเดอร์ที่จัดเก็บที่มีระดับการซ้อนกันจำนวนมาก) หรือตัววางแผนการดำเนินการสืบค้น (หากเป็นคำสั่ง SQL สองสามคำที่ไม่มีการซ้อนกัน) ก่อน 90% ของเวลาที่คุณสามารถพบปัญหาได้ทันทีด้วยหนึ่งในสองเครื่องมือนี้