คำถามติดแท็ก database-internals

สำหรับคำถามทางเทคนิคเกี่ยวกับการทำงานภายในของเอ็นจินฐานข้อมูล

1
ลบ vs TRUNCATE
ฉันพยายามทำความเข้าใจกับความแตกต่างระหว่างคำสั่งDELETEและ TRUNCATEความเข้าใจของฉันเกี่ยวกับ internals ไปบางอย่างตาม: DELETE-> เครื่องมือฐานข้อมูลค้นหาและลบแถวออกจากหน้าข้อมูลที่เกี่ยวข้องและหน้าดัชนีทั้งหมดที่ป้อนแถวนั้น ดังนั้นยิ่งดัชนียิ่งใช้เวลาลบนานเท่าใด TRUNCATE -> เพียงแค่ลบหน้าข้อมูลของตารางทั้งหมดออกมาซึ่งจะเป็นตัวเลือกที่มีประสิทธิภาพมากขึ้นสำหรับการลบเนื้อหาของตาราง สมมติว่าข้างต้นถูกต้อง (โปรดแก้ไขให้ฉันถ้าไม่): โหมดการกู้คืนที่แตกต่างกันมีผลต่อแต่ละคำสั่งอย่างไร หากมีผลกระทบใด ๆ เลย เมื่อทำการลบดัชนีทั้งหมดจะถูกสแกนหรือเฉพาะดัชนีที่อยู่แถวนั้น? ฉันจะถือว่าดัชนีทั้งหมดถูกสแกน (และไม่ได้หา?) คำสั่งจำลองอย่างไร? คำสั่ง SQL ส่งและประมวลผลกับผู้สมัครสมาชิกแต่ละคนหรือไม่? หรือ MSSQL ฉลาดกว่านี้สักหน่อย

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

2
การปรับแผนให้เหมาะสมด้วยตัวอ่าน XML
ดำเนินการค้นหาจากที่นี่เพื่อดึงเหตุการณ์ deadlock ออกจากเซสชันเพิ่มเติมของเหตุการณ์ที่ขยายเริ่มต้น SELECT CAST ( REPLACE ( REPLACE ( XEventData.XEvent.value ('(data/value)[1]', 'varchar(max)'), '<victim-list>', '<deadlock><victim-list>'), '<process-list>', '</victim-list><process-list>') AS XML) AS DeadlockGraph FROM (SELECT CAST (target_data AS XML) AS TargetData FROM sys.dm_xe_session_targets st JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address WHERE [name] = 'system_health') AS Data CROSS APPLY TargetData.nodes ('//RingBufferTarget/event') AS …

1
เหตุใดการสแกนจึงเร็วกว่าการค้นหาคำนี้
ฉันสามารถสร้างปัญหาประสิทธิภาพการสืบค้นที่ฉันจะอธิบายได้อย่างไม่คาดคิด ฉันกำลังมองหาคำตอบที่มุ่งเน้นไปที่ภายใน บนเครื่องของฉันเคียวรีต่อไปนี้ทำการสแกนดัชนีแบบคลัสเตอร์และใช้เวลาประมาณ 6.8 วินาทีของเวลา CPU: SELECT ID1, ID2 FROM two_col_key_test WITH (FORCESCAN) WHERE ID1 NOT IN ( N'1', N'2',N'3', N'4', N'5', N'6', N'7', N'8', N'9', N'10', N'11', N'12',N'13', N'14', N'15', N'16', N'17', N'18', N'19', N'20' ) AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER …

1
สถิติเก็บอยู่ใน SQL Server อยู่ที่ไหน
สถิติที่ใช้โดยเครื่องมือเพิ่มประสิทธิภาพข้อความค้นหาเก็บอยู่ในไฟล์ฐานข้อมูล SQL Server และบัฟเฟอร์พูลหรือไม่ โดยเฉพาะอย่างยิ่งมีวิธีที่จะคิดออกหน้าใช้สถิติโดยใช้ DMVs และ / หรือ DBCC หรือไม่ ฉันเป็นเจ้าของทั้ง SQL Server 2008 Internals และ SQL Server Internals และการแก้ไขปัญหาหนังสือและไม่มีใครพูดถึงโครงสร้างทางกายภาพของสถิติ หากพวกเขาฉันไม่สามารถค้นหาข้อมูลนี้

1
ตรรกะอ่านแตกต่างกันเมื่อเข้าถึงข้อมูล LOB เดียวกัน
นี่คือการทดสอบสามแบบที่อ่านข้อมูลเดียวกัน แต่รายงานการอ่านเชิงตรรกะที่แตกต่างกันมาก: ติดตั้ง สคริปต์ต่อไปนี้สร้างตารางทดสอบที่มี 100 แถวเหมือนกันแต่ละแถวมีคอลัมน์xml ที่มีข้อมูลเพียงพอเพื่อให้แน่ใจว่าจะถูกเก็บไว้นอกแถว ในฐานข้อมูลการทดสอบของฉันความยาวของxml ที่สร้างขึ้นคือ 20,204 ไบต์สำหรับแต่ละแถว -- Conditional drop IF OBJECT_ID(N'dbo.XMLTest', N'U') IS NOT NULL DROP TABLE dbo.XMLTest; GO -- Create test table CREATE TABLE dbo.XMLTest ( ID integer IDENTITY PRIMARY KEY, X xml NULL ); GO -- Add 100 wide xml rows DECLARE @X …

2
เปลี่ยนคอลัมน์จาก NOT NULL เป็น NULL - เกิดอะไรขึ้นภายใต้ประทุน?
เรามีตารางที่มีแถว 2.3B อยู่ เราต้องการเปลี่ยนคอลัมน์จาก NOT NULL เป็น NULL คอลัมน์มีอยู่ในหนึ่งดัชนี (ไม่ใช่ดัชนีแบบคลัสเตอร์หรือ PK) ชนิดข้อมูลไม่เปลี่ยนแปลง (เป็น INT) เพียงความไร้ค่า คำสั่งดังต่อไปนี้: Alter Table dbo.Workflow Alter Column LineId Int NULL การดำเนินการใช้เวลาเกินกว่า 10 ก่อนที่เราจะหยุดมัน (เรายังไม่ปล่อยให้มันทำงานจนเสร็จเพราะมันเป็นการปิดกั้นและใช้เวลานานเกินไป) เราอาจคัดลอกตารางไปยังเซิร์ฟเวอร์ dev เพื่อทดสอบว่าใช้เวลานานเท่าใด แต่ฉันอยากรู้ถ้าใครรู้ว่าสิ่งที่ SQL Server ทำภายใต้ประทุนเมื่อแปลงจาก NOT NULL เป็น NULL นอกจากนี้ดัชนีที่ได้รับผลกระทบจะต้องได้รับการสร้างใหม่หรือไม่ แผนแบบสอบถามที่สร้างขึ้นไม่ได้ระบุว่าเกิดอะไรขึ้น ตารางในคำถามถูกทำคลัสเตอร์ (ไม่ใช่ฮีป)

1
โพรบแฮชคีย์และส่วนที่เหลือ
สมมติว่าเรามีคำถามเช่นนี้: select a.*,b.* from a join b on a.col1=b.col1 and len(a.col1)=10 สมมติว่าแบบสอบถามดังกล่าวจะใช้แฮร่วมและมีส่วนที่เหลือที่สำคัญการสอบสวนจะเป็นและที่เหลือจะเป็นcol1len(a.col1)=10 แต่ในขณะที่ดูตัวอย่างอื่นฉันสามารถเห็นทั้งโพรบและส่วนที่เหลือเป็นคอลัมน์เดียวกัน ด้านล่างนี้เป็นรายละเอียดเกี่ยวกับสิ่งที่ฉันพยายามจะพูด: ค้นหา: select * from T1 join T2 on T1.a = T2.a แผนการดำเนินการพร้อมโพรบและไฮไลต์ที่เหลือ: ข้อมูลการทดสอบ: create table T1 (a int, b int, x char(200)) create table T2 (a int, b int, x char(200)) set nocount on declare @i …

4
ดัชนีในคอลัมน์ข้อมูลควรจะไม่เป็นแบบคลัสเตอร์หรือไม่?
สำหรับตารางที่มีคอลัมน์ข้อมูลประจำตัวควรสร้างดัชนี PK / ไม่ซ้ำกันแบบคลัสเตอร์หรือไม่เป็นคลัสเตอร์สำหรับคอลัมน์ข้อมูลประจำตัวหรือไม่ เหตุผลคือดัชนีอื่น ๆ จะถูกสร้างขึ้นสำหรับการค้นหา แบบสอบถามที่ใช้ดัชนี nonclustered (บนฮีป) และส่งกลับคอลัมน์ที่ไม่ครอบคลุมโดยดัชนีจะใช้ตรรกะ I / O (LIO) น้อยลงเนื่องจากไม่มีดัชนี b-tree ที่ทำคลัสเตอร์พิเศษค้นหาขั้นตอน? create table T ( Id int identity(1,1) primary key, -- clustered or non-clustered? (surrogate key, may be used to join another table) A .... -- A, B, C have mixed data type …

2
เหตุใดจึงใช้เวลานานกว่าในการสร้างดัชนีหลังจากขนาดคอลัมน์เพิ่มขึ้น
ผู้ขายของเราเปลี่ยนความกว้างของคอลัมน์ในเกือบทุกคอลัมน์ในฐานข้อมูลทั้งหมด ฐานข้อมูลอยู่ที่ประมาณ 7TB, 9000+ ตาราง เรากำลังพยายามสร้างดัชนีบนตารางที่มี 5.5 พันล้านแถว ก่อนการอัพเกรดของผู้ขายเราสามารถสร้างดัชนีได้ภายใน 2 ชั่วโมง ตอนนี้ต้องใช้เวลาหลายวัน สิ่งที่พวกเขาทำคือเพิ่มขนาด varchar (xx) เป็น varchar (256) ดังนั้นคอลัมน์ส่วนใหญ่เคยเป็น varchar (18) หรือ varchar (75) เป็นต้น อย่างไรก็ตามคีย์หลักประกอบด้วย 6 คอลัมน์ที่มีความกว้างรวมกันคือ 126 ตัวอักษร หลังจากอัปเกรดแล้วคีย์หลักคือ 1283 ตัวอักษรซึ่งละเมิดข้อ จำกัด ของเซิร์ฟเวอร์ SQL 900 ตัวอักษร ความกว้างคอลัมน์ของตารางทั้งหมดเพิ่มขึ้นจากการนับรวม varchar รวม 1049 ถึงการรวม varchar รวม 4009 ไม่มีข้อมูลเพิ่มขึ้นตารางไม่ใช้พื้นที่ "เกิน" มากกว่าที่เคยทำก่อนที่ความกว้างของคอลัมน์จะเพิ่มขึ้นทั้งหมด แต่ประสิทธิภาพในการสร้างบางอย่างเรียบง่ายเช่นเดียวกับดัชนีขณะนี้ใช้เวลานานเกินไป …

2
อะไรคือความแตกต่างระหว่างหน้าเว็บแบบ leaf และแบบ non-leaf?
ฉันได้รับการเรียกใช้รายงานการใช้งานดัชนีบางส่วนและฉันพยายามที่จะได้รับความหมายของใบและNon-ใบ ดูเหมือนว่าจะมีทั้งส่วนแทรกและส่วนที่ไม่ใช่ใบไม้การอัปเดตการลบการรวมหน้าและการจัดสรรหน้า ฉันไม่รู้จริงๆว่ามันหมายถึงอะไรหรือถ้ามีคนหนึ่งดีกว่าคนอื่น หากใครบางคนสามารถให้คำจำกัดความที่เรียบง่ายของแต่ละคนและอธิบายว่าทำไมเรื่อง Leaf หรือ Non-leaf ก็จะได้รับการชื่นชม!

1
ที่เก็บข้อมูลดัชนีแบบไม่คลัสเตอร์บนเสาหลักแบบคลัสเตอร์
ใน SQL Server ดัชนี nonclustered ที่ไม่ซ้ำกันในตารางrowstoreประกอบด้วยที่คั่นหน้าของวัตถุฐาน(RID หรือคีย์การทำคลัสเตอร์) ที่ทุกระดับของโครงสร้างดัชนีที่ไม่เป็นคลัสเตอร์ บุ๊กมาร์กจะถูกจัดเก็บเป็นส่วนหนึ่งของคีย์ดัชนีที่ไม่เป็นคลัสเตอร์ในทุกระดับดัชนี ในทางตรงกันข้ามถ้าดัชนี nonclustered เป็นที่ไม่ซ้ำกันที่คั่นเป็นปัจจุบันเท่านั้นที่ใบระดับของดัชนี - ไม่ได้เป็นส่วนหนึ่งของคีย์ (บุ๊กเป็นปัจจุบันเป็นหนึ่งหรือคอลัมน์รวมมากขึ้นในผล) ใน SQL Server 2016 เป็นไปได้ที่จะสร้างดัชนี b-tree แบบ nonclustered บนตารางเชิงคอลัมน์ (อันที่มีดัชนี columnstore แบบคลัสเตอร์) อะไรคือ 'บุ๊คมาร์ค' ที่ใช้สำหรับดัชนี b-tree แบบไม่คลัสเตอร์บนตาราง columnstore แบบคลัสเตอร์ ความแตกต่างระหว่างดัชนีที่ไม่ซ้ำแบบไม่เจาะจงและไม่ซ้ำแบบคลัสเตอร์ที่อธิบายไว้ข้างต้นยังคงมีผลอยู่หรือไม่?

4
การวางคอลัมน์ PostgreSQL 9.6 และผลข้างเคียงต่อฟังก์ชัน SQL ด้วย CTE
ถ้าฉันมีตารางที่มี 3 คอลัมน์ - พูด A, B และ D - และฉันต้องแนะนำใหม่ - พูด C เพื่อแทนที่ตำแหน่งปัจจุบันของ D ฉันจะใช้วิธีการต่อไปนี้: แนะนำ 2 คอลัมน์ใหม่เป็น C และ D2 คัดลอกเนื้อหาของ D ถึง D2 ลบ D. เปลี่ยนชื่อ D2 เป็น D คำสั่งซื้อใหม่จะเป็น A, B, C และ D ฉันคิดว่านี่เป็นวิธีปฏิบัติที่ถูกต้องตามกฎหมายเพราะจนถึงตอนนี้มันก็ไม่มีปัญหา อย่างไรก็ตามวันนี้ฉันเจอปัญหาเมื่อฟังก์ชั่นที่ดำเนินการคำสั่งบนตารางเดียวกันส่งคืนข้อผิดพลาดต่อไปนี้: table row type and query-specified row type do not …

1
ค่าใช้จ่ายสำหรับ varchar (n) คืออะไร?
ฉันต้องการถามถึงความหมายของส่วนนี้จากPostgres docเกี่ยวกับvarchar(n)ประเภท: ความต้องการพื้นที่เก็บข้อมูลสำหรับสตริงสั้น (สูงสุด 126 ไบต์) คือ 1 ไบต์บวกกับสตริงจริงซึ่งรวมถึงการเว้นวรรคเว้นวรรคในกรณีของอักขระ สตริงที่ยาวกว่ามี 4 ไบต์ของค่าใช้จ่ายแทน 1 สมมติว่าฉันมีvarchar(255)ทุ่งนา และตอนนี้คำสั่งต่อไปนี้: หากฟิลด์นี้มีสตริง 10 ไบต์ค่าใช้จ่ายอยู่ที่ 1 ไบต์ ดังนั้นสตริงจะใช้ 11 ไบต์ ถ้าเขตข้อมูลถือสตริงที่ใช้ 140 ไบต์ค่าใช้จ่ายอยู่ที่ 4 ไบต์ ดังนั้นสตริงจะใช้ 144 ไบต์ ข้อความข้างต้นเป็นจริงหรือไม่? ที่นี่มีคนเข้าใจเอกสารเช่นเดียวกับผม แต่ที่นี่มีคนระบุค่าใช้จ่ายอยู่เสมอ 4 ไบต์ที่นี่ ?

1
การประเมินภาวะเชิงหัวใจนอกฮิสโตแกรม
ติดตั้ง ฉันมีปัญหาในการทำความเข้าใจการประเมินความสำคัญเชิงหัวใจ นี่คือการตั้งค่าการทดสอบของฉัน: เวอร์ชัน 2010 ของฐานข้อมูล Stack Overflow SQL Server 2017 CU15 + GDR (KB4505225) - 14.0.3192.2 CE ใหม่ (ระดับความเข้ากันได้ 140) ฉันมี proc นี้: USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO ไม่มีดัชนีหรือสถิติที่ไม่ใช่คลัสเตอร์ในdbo.Postsตาราง …

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