เมื่อใดควรสร้างสถิติแทนการสร้างดัชนี

ฉันได้พบข้อมูลมากมายเกี่ยวกับสิ่งที่ STATISTICS : วิธีการดูแลรักษาวิธีการสร้างด้วยตนเองหรือโดยอัตโนมัติจากแบบสอบถามหรือดัชนีและอื่น ๆ แต่ผมได้รับไม่สามารถที่จะหาใด ๆคำแนะนำหรือ "วิธีปฏิบัติที่ดีที่สุด" ข้อมูลเกี่ยวกับเมื่อเพื่อสร้าง: สถานการณ์ใดที่ได้ประโยชน์จากวัตถุสถิติที่สร้างขึ้นด้วยตนเองมากกว่าจากดัชนี ฉันได้เห็นสถิติที่สร้างขึ้นด้วยตนเองที่กรองแล้วช่วยสอบถามในตารางที่แบ่งพาร์ติชัน (เนื่องจากสถิติที่สร้างขึ้นสำหรับดัชนีครอบคลุมทั้งตารางและไม่ใช่ต่อพาร์ติชัน - ความสุกใส!) แต่แน่นอนว่าต้องมีสถานการณ์อื่น ๆ ที่จะได้รับประโยชน์จากวัตถุสถิติ ไม่ต้องการรายละเอียดของดัชนีหรือไม่คุ้มค่ากับการบำรุงรักษาดัชนีหรือเพิ่มโอกาสในการบล็อค / ล็อคตาย

@JonathanFite ในความคิดเห็นพูดถึงความแตกต่างระหว่างดัชนีและสถิติ:

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

นั่นคือข้อมูลที่ดีส่วนใหญ่เป็นเพราะมันช่วยให้ฉันชี้แจงคำถามของฉัน:

วิธีการที่ไม่ทราบนี้ (หรือข้อมูลทางเทคนิคอื่น ๆ ใด ๆ เกี่ยวกับสิ่งที่และวิธีการ s ที่เกี่ยวข้องกับพฤติกรรมและธรรมชาติของSTATISTICS) ช่วยตรวจสอบเมื่อให้เลือกCREATE STATISTICSมากกว่าCREATE INDEXโดยเฉพาะอย่างยิ่งเมื่อมีการสร้างดัชนีจะสร้างที่เกี่ยวข้องกับSTATISTICSวัตถุ? สถานการณ์ใดที่จะให้บริการที่ดีขึ้นโดยมีเพียงข้อมูลสถิติและไม่มีดัชนี

มันจะเป็นซุปเปอร์ duper ประโยชน์ถ้าเป็นไปได้ที่จะมีตัวอย่างการทำงานของสถานการณ์ที่วัตถุที่เป็นแบบที่ดีกว่าSTATISTICSINDEX

เนื่องจากฉันเป็นผู้เรียนด้วยสายตา / นักคิดฉันคิดว่ามันอาจช่วยให้เห็นความแตกต่างระหว่างSTATISTICSและINDEXes เคียงข้างกันเป็นวิธีที่เป็นไปได้ในการช่วยกำหนดว่าเมื่อใดSTATISTICSจะเป็นทางเลือกที่ดีกว่า

Thingy           PROs                             CONs
-------          ----------                       -------------------
INDEX            * Can help sorts.                * Takes up space.
                 * Contains data (can             * Needs to be maintained (extra I/O).
                   "cover" a query).              * More chances for blocking / dead-locks.

STATISTICS       * Takes up very little space.    * Cannot help sorts.
                 * Lighter maintenance / won't    * Cannot "cover" queries.
                   slow down DML operations.
                 * Does not increase chances
                   of blocking / dead-locks.

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

ดัชนีเซิร์ฟเวอร์ SQL เทียบกับสถิติ

คำถามเกี่ยวกับสถิติ SQL Server ที่เราอายเกินกว่าจะถามได้

สถิติ. ฮิสโทแกรมหลายสีเป็นไปได้หรือไม่

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

คุณมีคำถามหมุนรอบ - เมื่อไรควรสร้างสถิติและสร้างดัชนี (ซึ่งสร้างสถิติ) เมื่อใด

จากบันทึกภายในเซิร์ฟเวอร์ sql ของฉัน (SQLSkills class- IE1 และ IE2) และสมุด SQL internals internalsด้านล่างคือความเข้าใจที่จำกัดของฉัน:

สถิติของ SQL Server ไม่ได้มี แต่วัตถุระบบที่มีข้อมูลสำคัญเกี่ยวกับค่าคีย์ดัชนีและค่าคอลัมน์ปกติ

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

SQL Server จะไม่ใช้ดัชนี nonclustered เมื่อมันประเมินว่าไม่มีขนาดใหญ่ ของการดำเนินการลูป KEY หรือ RID จะต้องใช้ดังนั้นจึงเก็บสถิติเกี่ยวกับดัชนี (และคอลัมน์) ซึ่งจะช่วยในการประมาณค่าดังกล่าว

มี 2 ​​สิ่งสำคัญเกี่ยวกับสถิติ:

1. ฮิสโตแกรมเก็บข้อมูลเกี่ยวกับการกระจายข้อมูลสำหรับคอลัมน์สถิติ (ดัชนี) ซ้ายสุดเท่านั้น นอกจากนี้ยังเก็บข้อมูลเกี่ยวกับความหนาแน่นหลายคอลัมน์ของค่าคีย์ ดังนั้นฮิสโตแกรมจึงจัดเก็บการกระจายข้อมูลสำหรับคอลัมน์สถิติทางซ้ายสุดเท่านั้น

2. SQL Server จะรักษาอย่างน้อย 200 ขั้นตอนในฮิสโตแกรมโดยไม่คำนึงถึงขนาดของตาราง ช่วงเวลาที่ครอบคลุมโดยแต่ละขั้นตอนฮิสโตแกรมจะเพิ่มขึ้นเมื่อตารางโตขึ้นซึ่งนำไปสู่สถิติ "แม่นยำน้อยลง" สำหรับตารางขนาดใหญ่

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

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

อ้างอิง:

• สถิติคอลัมน์ให้เครื่องมือเพิ่มประสิทธิภาพโดย Kalen Delaney
• สถิติการสาปแช่งและสถิติ - Statman คืออะไร โดย Conor Cunningham

หมายเหตุ: คนเหมือนพอลไวท์หรืออาโรเบอร์ทรานด์สามารถสอดเพื่อให้สีที่มากขึ้นให้กับคำถามที่ดีของคุณ

ฉันว่าคุณต้องการดัชนีเมื่อคุณจำเป็นต้องสามารถ จำกัด จำนวนข้อมูล / รับข้อมูลที่ถูกต้องได้อย่างรวดเร็วตามเขตข้อมูล

คุณต้องการสถิติเมื่อคุณต้องการเครื่องมือเพิ่มประสิทธิภาพเพื่อทำความเข้าใจธรรมชาติของข้อมูลเพื่อให้สามารถดำเนินการในวิธีที่ดีที่สุด

สิ่งที่ฉันได้คิดออกสถิติการกรองช่วยเมื่อคุณมีความคล่องแคล่วในข้อมูลของคุณที่มีผลต่อแผนอย่างมากตัวอย่างเช่นในสแต็คล้นผู้ใช้จำนวนน้อยมีโพสต์จำนวนมากดังนั้นการใช้โพสต์เฉลี่ยต่อผู้ใช้เท่านั้น ดังนั้นคุณสามารถสร้างสถิติที่กรองตาม userId ตามชื่อผู้ใช้แล้ว SQL Server ควรรู้ว่าเมื่อชื่อผู้ใช้นี้อยู่ในแบบสอบถามนี่คือ ID ผู้ใช้ที่จะได้รับและควรจะสามารถเข้าใจว่า ฟิลด์ที่มีการจัดทำดัชนีในตารางโพสต์จะมีแถวจำนวนมากที่มี ID นั้นเนื่องจากมีฮิสโตแกรมอยู่ที่นั่น ด้วยค่าเฉลี่ยคุณไม่สามารถทำได้

จาก 70-461 หนังสือฝึกอบรมโดย Itzik Ben-Gan

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