คำถามติดแท็ก clustered-index

ประเภทของดัชนีส่วนใหญ่ที่ใช้ใน SQL-Server ซึ่งจัดเรียงข้อมูลของตารางกับดัชนี

3
แนวคิดของดัชนีคลัสเตอร์ในการออกแบบ DB มีความหมายเมื่อใช้ SSD หรือไม่
เมื่อออกแบบ SQL data data schema ของเซิร์ฟเวอร์และเคียวรีที่ตามมา, sprocs, views, ฯลฯ แนวคิดของดัชนีคลัสเตอร์และลำดับของข้อมูลบนดิสก์มีเหตุผลหรือไม่ที่จะต้องพิจารณาการออกแบบ DB ที่ทำให้ติดตั้งบนแพลตฟอร์ม SSD อย่างชัดเจน ? http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx "ดัชนีคลัสเตอร์กำหนดลำดับทางกายภาพของข้อมูลในตาราง" บนแพลตฟอร์มดิสก์แบบฟิสิคัลการออกแบบเพื่อพิจารณาว่าเหมาะสมสำหรับฉันเมื่อสแกนฟิสิคัลข้อมูลเพื่อดึงแถว "เรียงตามลำดับ" อาจมีประสิทธิภาพมากกว่าการค้นหาในตาราง บนแพลตฟอร์ม SSD การเข้าถึงการอ่านข้อมูลทั้งหมดใช้การค้นหาที่เหมือนกัน ไม่มีแนวคิดของ "การสั่งซื้อทางกายภาพ" และการอ่านข้อมูลไม่ใช่ "ต่อเนื่อง" ในแง่ที่ว่าบิตถูกเก็บไว้ในซิลิคอนชิ้นเดียวกัน ดังนั้นในกระบวนการกำหนดฐานข้อมูลแอปพลิเคชันการพิจารณาดัชนีกลุ่มที่เกี่ยวข้องกับแพลตฟอร์มนี้คืออะไร? ความคิดเริ่มต้นของฉันคือว่าไม่ใช่เพราะแนวคิดของ "ข้อมูลที่สั่งซื้อ" ไม่ได้ใช้กับการจัดเก็บข้อมูล SSD และการค้นหา / การเพิ่มประสิทธิภาพการกู้คืน แก้ไข:ฉันรู้ว่า SQL Server จะสร้างหนึ่งฉันแค่ปรัชญาเกี่ยวกับว่ามันเหมาะสมที่จะคิดในระหว่างการออกแบบ / การเพิ่มประสิทธิภาพ

6
เหตุใดปุ่มลำดับ GUID จึงทำงานได้เร็วกว่าปุ่ม INT ตามลำดับในกรณีทดสอบของฉัน
หลังจากที่ถามนี้คำถามเปรียบเทียบลำดับและ guid ของที่ไม่ใช่ลำดับผมพยายามที่จะเปรียบเทียบประสิทธิภาพ INSERT เมื่อวันที่ 1) ตารางที่มีคีย์หลัก GUID เริ่มต้นตามลำดับด้วยnewsequentialid()และ 2) ตารางที่มีคีย์หลัก INT identity(1,1)เริ่มต้นตามลำดับด้วย ฉันคาดว่าหลังจะเร็วที่สุดเนื่องจากมีความกว้างน้อยกว่าจำนวนเต็มและมันก็ดูเหมือนจะง่ายกว่าในการสร้างจำนวนเต็มตามลำดับกว่า GUID ตามลำดับ แต่ด้วยความประหลาดใจของฉัน INSERTs บนตารางที่มีคีย์จำนวนเต็มช้ากว่าตาราง GUID ตามลำดับอย่างมีนัยสำคัญ นี่แสดงการใช้เวลาเฉลี่ย (มิลลิวินาที) สำหรับการทดสอบการทำงาน: NEWSEQUENTIALID() 1977 IDENTITY() 2223 มีใครอธิบายเรื่องนี้ได้บ้าง มีการใช้การทดลองต่อไปนี้: SET NOCOUNT ON CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID() PRIMARY KEY, SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100)) …

3
ประสิทธิภาพการทำงานของดัชนีที่ไม่ทำคลัสเตอร์กับ Heaps เทียบกับดัชนีแบบคลัสเตอร์
เอกสารไวท์ 2007 นี้เปรียบเทียบประสิทธิภาพสำหรับคำสั่งเลือก / แทรก / ลบ / อัปเดตและการเลือกช่วงแต่ละรายการบนตารางที่จัดเป็นดัชนีแบบคลัสเตอร์เทียบกับบนตารางที่จัดเป็นฮีปที่มีดัชนีที่ไม่ใช่คลัสเตอร์ในคอลัมน์คีย์เดียวกันกับ CI โต๊ะ. โดยทั่วไปตัวเลือกดัชนีแบบคลัสเตอร์จะทำงานได้ดีขึ้นในการทดสอบเนื่องจากมีเพียงโครงสร้างเดียวที่ต้องบำรุงรักษาและเนื่องจากไม่จำเป็นต้องทำการค้นหาบุ๊กมาร์ก กรณีที่น่าสนใจอย่างหนึ่งที่อาจไม่ครอบคลุมในเอกสารจะเป็นการเปรียบเทียบระหว่างดัชนีที่ไม่ทำคลัสเตอร์กับฮีปเทียบกับดัชนีที่ไม่ทำคลัสเตอร์กับดัชนีที่ทำคลัสเตอร์ ในอินสแตนซ์นั้นฉันคาดว่า heap อาจทำงานได้ดีขึ้นเช่นเดียวกับ NCI leaf leaf ระดับ SQL Server ที่มี RID เพื่อติดตามโดยตรงแทนที่จะต้องการสำรวจดัชนีคลัสเตอร์ มีใครทราบบ้างเกี่ยวกับการทดสอบอย่างเป็นทางการที่คล้ายกันซึ่งดำเนินการในพื้นที่นี้และถ้าเป็นเช่นนั้นผลลัพธ์คืออะไร

2
ลำดับของคอลัมน์ในดัชนี PK มีความสำคัญหรือไม่?
ฉันมีตารางที่มีขนาดใหญ่มากไม่กี่แห่งที่มีโครงสร้างพื้นฐานแบบเดียวกัน แต่ละคนมีRowNumber (bigint)และDataDate (date)คอลัมน์ ข้อมูลถูกโหลดโดยใช้ SQLBulkImport ทุกคืนและไม่มีการโหลดข้อมูล "ใหม่" - บันทึกประวัติ (SQL Standard ไม่ใช่ Enterprise ดังนั้นจึงไม่มีการแบ่งพาร์ติชัน) เนื่องจากข้อมูลแต่ละบิตจำเป็นต้องเชื่อมโยงกลับไปที่ระบบอื่น ๆ และการRowNumber/DataDateรวมกันแต่ละครั้งไม่ซ้ำกันนั่นคือคีย์หลักของฉัน ฉันสังเกตเห็นว่าเนื่องจากวิธีที่ฉันกำหนด PK ใน SSMS Table Designer RowNumberแสดงรายการที่หนึ่งและDataDateสอง ฉันยังสังเกตเห็นว่าการกระจายตัวของฉันมักจะสูงมาก ~ 99% ตอนนี้เพราะแต่ละรายการDataDateปรากฏเพียงครั้งเดียวฉันคาดว่าเครื่องมือสร้างดัชนีจะเพิ่มไปยังหน้าเว็บในแต่ละวัน แต่ฉันสงสัยว่าจริง ๆ แล้วการจัดทำดัชนีอิงตามลำดับRowNumberแรกหรือไม่และต้องเปลี่ยนทุกอย่างอื่นหรือไม่ Rownumberไม่ใช่คอลัมน์ข้อมูลประจำตัว แต่เป็น int ที่สร้างขึ้นโดยระบบภายนอก (น่าเศร้า) DataDateมันรีเซ็ตในช่วงเริ่มต้นของแต่ละคน ตัวอย่างข้อมูล RowNumber | DataDate | a | b | c..... 1 |2013-08-01| …

3
สถานการณ์การใช้งานที่ถูกต้องสำหรับตาราง HEAP คืออะไร
ขณะนี้ฉันกำลังนำเข้าข้อมูลบางอย่างไปยังระบบดั้งเดิมและพบว่าระบบนี้ไม่ได้ใช้ดัชนีคลัสเตอร์เดียว การค้นหาโดย Google อย่างรวดเร็วแนะนำให้ฉันรู้จักกับแนวคิดของตาราง HEAP และตอนนี้ฉันอยากรู้ว่าในสถานการณ์การใช้งานใดที่ควรใช้ตาราง HEAP บนตารางคลัสเตอร์มากกว่านี้ เท่าที่ฉันเข้าใจตาราง HEAP จะมีประโยชน์สำหรับตารางการตรวจสอบและ / หรือตำแหน่งที่แทรกเกิดขึ้นบ่อยกว่าการเลือก มันจะประหยัดพื้นที่ดิสก์และดิสก์ I / O เนื่องจากไม่มีดัชนีคลัสเตอร์ที่ต้องบำรุงรักษาและการแตกแฟรกเมนต์เพิ่มเติมจะไม่เป็นปัญหาเนื่องจากการอ่านที่หายากมาก

3
ทำไมดัชนี REBUILD ไม่ลดการแยกส่วนดัชนี?
ฉันใช้ ALTER INDEX REBUILD เพื่อลบการแตกแฟรกเมนต์ดัชนี ในบางกรณี REBUILD ดูเหมือนจะไม่ลบการกระจายตัวของนี้ อะไรคือสาเหตุที่ REBUILD ไม่ลบการแยกส่วน? ดูเหมือนว่าสิ่งนี้จะเกิดขึ้นโดยเฉพาะกับดัชนีขนาดเล็ก

3
INSERT ที่มีประสิทธิภาพเข้าสู่ตารางที่มีดัชนีเป็นกลุ่ม
ฉันมีคำสั่ง SQL ที่แทรกแถวลงในตารางที่มีดัชนีคลัสเตอร์ในคอลัมน์ TRACKING_NUMBER เช่น: INSERT INTO TABL_NAME (TRACKING_NUMBER, COLB, COLC) SELECT TRACKING_NUMBER, COL_B, COL_C FROM STAGING_TABLE คำถามของฉันคือ - มันช่วยในการใช้คำสั่งย่อย ORDER BY ในคำสั่ง SELECT สำหรับคอลัมน์ดัชนีคลัสเตอร์หรือไม่หรือการได้รับผลประโยชน์ใด ๆ จะได้รับผลกระทบจากการเรียงลำดับพิเศษที่จำเป็นสำหรับคำสั่ง ORDER BY?

4
'หลีกเลี่ยงการสร้างดัชนีแบบคลัสเตอร์โดยยึดตามคีย์ที่เพิ่มขึ้น' เป็นตำนานมาจาก SQL Server 2000 หรือไม่
ฐานข้อมูลของเราประกอบด้วยตารางจำนวนมากโดยส่วนใหญ่ใช้คีย์ตัวแทนจำนวนเต็มเป็นคีย์หลัก ประมาณครึ่งหนึ่งของคีย์หลักเหล่านี้อยู่ในคอลัมน์ข้อมูลประจำตัว การพัฒนาฐานข้อมูลเริ่มต้นขึ้นในยุคของ SQL Server 6.0 หนึ่งในกฎที่ใช้จากจุดเริ่มต้นคือหลีกเลี่ยงการสร้างดัชนีคลัสเตอร์บนพื้นฐานของความสำคัญที่เพิ่มขึ้นในขณะที่คุณพบในเหล่านี้ดัชนีเคล็ดลับการเพิ่มประสิทธิภาพ ตอนนี้ใช้ SQL Server 2005 และ SQL Server 2008 ฉันมีความประทับใจอย่างมากว่าสถานการณ์เปลี่ยนไป ในขณะเดียวกันคอลัมน์คีย์หลักเหล่านี้เป็นตัวเลือกแรกที่สมบูรณ์แบบสำหรับดัชนีกลุ่มของตาราง

1
ใน SQL Server เหตุใดการสแกนย้อนหลังของดัชนีคลัสเตอร์จึงไม่สามารถใช้การขนานได้
ฉันอ่านเกี่ยวกับ SQL Server internals และหนังสือหรือบล็อกทุกฉบับที่กล่าวถึงเรื่องการสแกนย้อนหลัง การสแกนย้อนหลังของดัชนีคลัสเตอร์ไม่สามารถใช้การขนาน โพสต์เดียวที่กล่าวถึงบางสิ่งอยู่ด้านล่างนี้ โพสต์บอกว่าทีม SQL Server ไม่ได้ใช้การปรับให้เหมาะสมที่จำเป็นสำหรับการสแกนย้อนหลัง https://www.itprotoday.com/sql-server/descending-indexes เนื่องจากเพจระดับลีฟนั้นถูกเชื่อมโยงโดยใช้ลิสต์ที่มีการลิงก์ซ้ำกันสองครั้งฉันไม่เข้าใจว่าทำไมการสแกนย้อนหลังจึงแตกต่างจากการสแกนไปข้างหน้า การชี้แจงใด ๆ ที่ชื่นชมจริง ๆ

1
ปัจจัยใดบ้างที่เข้าสู่ดัชนีแบบกลุ่มของดัชนีการดูที่ถูกเลือก?
โดยสังเขป ปัจจัยใดที่พวกเขาค้นหาการเลือกดัชนีของมุมมองที่จัดทำดัชนีไว้ของเครื่องมือเพิ่มประสิทธิภาพ สำหรับฉันการดูที่จัดทำดัชนีดูเหมือนจะท้าทายสิ่งที่ฉันเข้าใจเกี่ยวกับวิธีที่เครื่องมือเพิ่มประสิทธิภาพเลือกดัชนี ฉันเคยเห็นสิ่งนี้ถามมาก่อนแต่ OP ไม่ได้รับการตอบรับดีเกินไป ฉันกำลังมองหาป้ายบอกทางแต่ฉันจะปรุงตัวอย่างหลอกแล้วโพสต์ตัวอย่างจริงด้วย DDL, เอาท์พุท, ตัวอย่างมากมาย สมมติว่าฉันใช้ Enterprise 2008+ เข้าใจ with(noexpand) ตัวอย่างหลอก ใช้ตัวอย่างปลอมนี้: ฉันสร้างมุมมองที่มี 22 ตัวกรองตัวกรอง 17 ตัวและม้าวงเวียนที่ตัดแถวตารางจำนวน 10 ล้านแถว มุมมองนี้มีราคาแพง (ใช่ด้วยทุน E) ที่จะทำให้เป็นจริง ฉันจะวางแผนและสร้างดัชนีมุมมอง SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84จากนั้น ในตรรกะของเครื่องมือเพิ่มประสิทธิภาพที่ทำให้ฉันมีการเชื่อมต่อที่ขีดเส้นใต้ ผลลัพธ์: ไม่มีคำแนะนำ: 4825 อ่าน 720 แถว 47 cpu มากกว่า 76ms และราคาต้นไม้ย่อยโดยประมาณ 0.30523 …

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


2
ดัชนีใดที่จะใช้กับค่าซ้ำจำนวนมาก
ลองทำข้อสมมติสองสามข้อ: ฉันมีตารางที่มีลักษณะดังนี้: a | b ---+--- a | -1 a | 17 ... a | 21 c | 17 c | -3 ... c | 22 ข้อเท็จจริงเกี่ยวกับชุดของฉัน: ขนาดของตารางทั้งหมดคือ ~ 10 10แถว ฉันมีแถว ~ 100k ที่มีค่าaในคอลัมน์aคล้ายกับค่าอื่น ๆ (เช่นc) นั่นหมายถึง ~ 100k ค่าที่แตกต่างในคอลัมน์ 'a' select sum(b) from t where a = 'c'ส่วนใหญ่เป็นคำสั่งของฉันจะอ่านทั้งหมดหรือส่วนใหญ่ของค่าสำหรับค่าที่กำหนดในเช่น …

1
ดัชนีแบบคลัสเตอร์ไม่ได้ใช้ในคำสั่งลบ
ฉันมีตาราง SQL Server ที่กำหนดดังนี้ CREATE TABLE [dbo].[Production_Detail] ( [Id] [bigint] NOT NULL DEFAULT (NEXT VALUE FOR [dbo].[Production_Detail_Seq]), [Meta_Data_ID] INT NOT NULL , [Production_Detail_Time] DATETIME NOT NULL, [Production_Detail_Time_Local] DATETIME NOT NULL, [Production_Detail_Value] FLOAT NULL, [IntegratedDM] BIT NOT NULL DEFAULT 0, [DailyIntegratedDM] BIT NOT NULL DEFAULT 0, [InsertedDate] DateTime NOT NULL, [ModifiedDate] …

2
PostgreSQL แตกต่างระหว่าง VACUUM FULL และ CLUSTER
ฉันมีตารางที่มีข้อมูลขนาด 200 GB และมีขนาด 180 GB โดยดัชนี 6 รายการ มันบวม 30% ดังนั้นฉันต้องการเรียกคืนพื้นที่ที่ไม่ต้องการครอบครอง มันเป็นคลัสเตอร์ในjob_id_idดัชนี x ดังนั้นเพื่อเรียกคืนพื้นที่ฉันต้องใช้clusterคำสั่งหรือvacuum fullคำสั่ง? ความแตกต่างระหว่างสองคำสั่งนี้คืออะไร? คือvacuum fullการสั่งซื้อตามคอลัมน์บางเช่นเดียวกับclusterคำสั่ง? ดัชนีถูกสร้างขึ้นใหม่ทั้งในคำสั่งหรือไม่? ในกรณีของฉันอันไหนจะเร็วกว่ากัน? เวอร์ชันของฐานข้อมูล PostgreSQL คือ 9.1

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