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

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

2
เหตุใดการสร้างดัชนีใหม่นี้จึงปรับปรุงประสิทธิภาพมากขึ้นเมื่อดัชนีที่มีอยู่รวมคอลัมน์ทั้งหมดในดัชนีใหม่
ฉันมีตารางบันทึกและ LogItem ฉันกำลังเขียนแบบสอบถามเพื่อดึงข้อมูลจากทั้งสองอย่าง มีหลายพันLogsและแต่ละคนLogสามารถมีได้มากถึง 125LogItems คำถามที่ถามมีความซับซ้อนดังนั้นฉันจึงข้ามมัน (ถ้ามีคนคิดว่ามันเป็นสิ่งสำคัญที่ฉันสามารถโพสต์ได้) แต่เมื่อฉันรันแผนแบบสอบถาม SSMS โดยประมาณมันบอกฉันว่าดัชนีที่ไม่เป็นคลัสเตอร์ใหม่จะปรับปรุงประสิทธิภาพได้สูงสุด 100% . Existing Index: Non-clustered Key Colums (LogItem): ParentLogID, DateModified, Name, DatabaseModified Query Plan Recommendation CREATE NONCLUSTERED INDEX [LogReportIndex] ON [dbo].[LogItem] ([ParentLogID],[DatabaseModified]) เพียงเพื่อความสนุกฉันสร้างดัชนีใหม่นี้และเรียกใช้คิวรีและสร้างความประหลาดใจให้กับฉันมากตอนนี้ใช้เวลาประมาณ 1 วินาทีในการเรียกใช้คิวรีของฉันก่อนที่จะนานกว่า 10 วินาที ฉันคิดว่าดัชนีที่มีอยู่ของฉันจะครอบคลุมแบบสอบถามใหม่นี้ดังนั้นคำถามของฉันคือเหตุผลที่สร้างดัชนีใหม่ในคอลัมน์เดียวที่ใช้ในแบบสอบถามใหม่ของฉันปรับปรุงประสิทธิภาพหรือไม่ ฉันควรมีดัชนีสำหรับชุดค่าผสมที่ไม่ซ้ำกันของคอลัมน์ที่ใช้ในส่วนwhereคำสั่งของฉันหรือไม่? หมายเหตุ: ฉันไม่คิดว่านี่เป็นเพราะ SQL Server กำลังแคชผลลัพธ์ของฉันฉันรันเคียวรีประมาณ 25-30 ครั้งก่อนที่ฉันจะสร้างดัชนีและใช้เวลาประมาณ 10-15 วินาทีหลังจากดัชนีตอนนี้สอดคล้องกัน ~ 1 …
19 sql-server  index 

2
ข้อ จำกัด ของคอลัมน์ที่ไม่ซ้ำกันที่กำหนดเองมีผลบังคับใช้เฉพาะถ้าหนึ่งคอลัมน์มีค่าเฉพาะ
เป็นไปได้หรือไม่ที่จะมีข้อ จำกัด คอลัมน์เฉพาะที่กำหนดเองดังต่อไปนี้ สมมติว่าฉันมีสองคอลัมน์subsetและtypeทั้งสองสตริง (แม้ว่าชนิดข้อมูลอาจไม่สำคัญ) ถ้าtypeเป็น "จริง" ฉันก็อยากจะผสมผสานtypeและsubsetเป็นเอกลักษณ์ มิฉะนั้นจะไม่มีข้อ จำกัด ฉันใช้ PostgreSQL 8.4 บนเดเบียน

2
วิธีการติดตั้งโมดูลเพิ่มเติม pg_trgm
ฉันต้องการทราบวิธีการติดตั้งโมดูลpg_tgrmตามที่ใช้ในรูปแบบการจัดทำดัชนีแบบ Trigram ที่ช่วยให้คุณทำรูปแบบการค้นหาที่ไม่ได้ทอดสมอบนดัชนี WHERE foo LIKE '%bar%';

6
ALTER INDEX ALL REBUILD ใช้พื้นที่บันทึกธุรกรรมมากขึ้นด้วยรูปแบบการกู้คืนข้อมูลที่ง่ายกว่าการสร้างดัชนีแต่ละรายการใหม่หรือไม่
การดำเนินการ "ALTER INDEX ALL REBUILD" ใน SQL Server 2012 ล้มเหลวเนื่องจากบันทึกธุรกรรมหมดพื้นที่ ดัชนีไม่เคยถูกจัดระเบียบใหม่หรือสร้างใหม่ดังนั้นการกระจายตัวจึงมากกว่า 80% สำหรับเกือบทั้งหมด DB ใช้รูปแบบการกู้คืนอย่างง่าย ฉันสันนิษฐานว่าต่อไปนี้การดำเนินการแต่ละดัชนีดำเนินการโดยรูปแบบ "ALL" ของคำสั่งข้อมูลบันทึกธุรกรรมจะถูกล้างออกก่อนที่จะสร้างดัชนีครั้งต่อไป นั่นเป็นวิธีการใช้งานจริงหรือดัชนีสร้างใหม่ราวกับว่าพวกเขาเป็นส่วนหนึ่งของการทำธุรกรรมเดียว? กล่าวอีกนัยหนึ่งฉันสามารถลดการเติบโตของบันทึกธุรกรรมโดยการเขียนสคริปต์เพื่อดำเนินการสร้างใหม่ทีละรายการหรือไม่ มีปัจจัยอื่น ๆ ที่ต้องพิจารณาอีกหรือไม่?
18 sql-server  index 

4
Memory Optimized Tables - พวกเขายากที่จะรักษาหรือไม่?
ฉันกำลังตรวจสอบประโยชน์ของการอัปเกรดจาก MS SQL 2012 เป็น 2014 หนึ่งในจุดขายที่ยิ่งใหญ่ของ SQL 2014 คือตารางที่ปรับให้เหมาะสมกับหน่วยความจำ ฉันพบว่ามีข้อ จำกัด บางประการเกี่ยวกับตารางที่เพิ่มประสิทธิภาพหน่วยความจำเช่น: ไม่มี(max)ฟิลด์ขนาด สูงสุด ~ 1KB ต่อแถว ไม่มีtimestampสาขา ไม่มีคอลัมน์ที่คำนวณ ไม่มีUNIQUEข้อ จำกัด สิ่งเหล่านี้มีคุณสมบัติเป็นสิ่งรบกวน แต่ถ้าฉันต้องการที่จะหลีกเลี่ยงพวกเขาเพื่อให้ได้รับผลประโยชน์จากการทำงานฉันสามารถวางแผนได้ นักเตะตัวจริงคือความจริงที่ว่าคุณไม่สามารถเรียกใช้ALTER TABLEคำสั่งได้และคุณจะต้องผ่านอุปกรณ์ตรวจจับนี้ทุกครั้งที่คุณเพิ่มฟิลด์ลงในINCLUDEรายการดัชนี นอกจากนี้ยังปรากฏว่าคุณต้องปิดผู้ใช้ออกจากระบบเพื่อที่จะเปลี่ยนแปลงสคีมาใด ๆ กับตาราง MO บนฐานข้อมูลสด ฉันพบว่าสิ่งนี้ช่างเลวร้ายเหลือเกินจนฉันไม่อยากเชื่อเลยว่าไมโครซอฟท์อาจลงทุนด้านการพัฒนาเป็นจำนวนมากในฟีเจอร์นี้ สิ่งนี้นำฉันไปสู่ข้อสรุปที่ว่าฉันต้องผ่านจุดผิดที่ผิดพลาด ฉันต้องเข้าใจผิดบางอย่างเกี่ยวกับตารางที่ปรับให้เหมาะสมกับหน่วยความจำซึ่งทำให้ฉันเชื่อว่าการบำรุงรักษามันยากกว่าที่เป็นจริง ดังนั้นฉันเข้าใจผิดอะไร คุณใช้ตาราง MO แล้วหรือยัง มีการสลับลับหรือกระบวนการบางอย่างที่ทำให้สามารถใช้งานและบำรุงรักษาได้จริงหรือไม่?

1
ทำไมคุณต้องจัดทำดัชนี text_pattern_ops ในคอลัมน์ข้อความ
วันนี้ฐานข้อมูลเจ็ดแห่งในเจ็ดสัปดาห์แนะนำให้ฉันรู้จักกับดัชนีผู้ดำเนินการต่อ คุณสามารถจัดทำดัชนีสตริงสำหรับรูปแบบที่ตรงกับแบบสอบถามก่อนหน้านี้โดยสร้างtext_pattern_opsดัชนีระดับผู้ประกอบการตราบใดที่มีการจัดทำดัชนีเป็นตัวพิมพ์เล็ก CREATE INDEX moves_title_pattern ON movies ( (lower(title) text_pattern_ops); เราใช้text_pattern_opsเพราะชื่อเป็นข้อความประเภท หากคุณจำเป็นต้องดัชนี varchars, ตัวอักษรหรือชื่อที่ใช้ปฏิบัติการที่เกี่ยวข้อง: varchar_pattern_ops, และbpchar_pattern_opsname_pattern_ops ฉันพบตัวอย่างที่ทำให้สับสนจริงๆ ทำไมการทำเช่นนี้จึงมีประโยชน์ หากคอลัมน์เป็นข้อความประเภทจะไม่ถูกแปลงเป็นประเภทอื่น (varchar, char, name) เป็นข้อความก่อนที่จะใช้เป็นค่าการค้นหาหรือไม่ ดัชนีนั้นมีพฤติกรรมแตกต่างจากที่ใช้ตัวดำเนินการเริ่มต้นอย่างไร CREATE INDEX moves_title_pattern ON movies (lower(title));

5
ไม่สามารถสร้างดัชนีที่กรองแล้วในคอลัมน์จากการคำนวณ
ในคำถามก่อนหน้านี้ของฉันเป็นความคิดที่ดีหรือไม่ที่จะปิดใช้งานการเลื่อนระดับล็อคในขณะที่เพิ่มคอลัมน์จากการคำนวณใหม่ลงในตาราง ฉันกำลังสร้างคอลัมน์จากการคำนวณ: ALTER TABLE dbo.tblBGiftVoucherItem ADD isUsGift AS CAST ( ISNULL( CASE WHEN sintMarketID = 2 AND strType = 'CARD' AND strTier1 LIKE 'GG%' THEN 1 ELSE 0 END , 0) AS BIT ) PERSISTED; คอลัมน์จากการคำนวณคือPERSISTEDและตามcomputed_column_definition (Transact-SQL) : ยืนกราน ระบุว่า Database Engine จะจัดเก็บค่าที่คำนวณในร่างกายและอัพเดตค่าเมื่อคอลัมน์อื่น ๆ ที่คอลัมน์ที่คำนวณขึ้นอยู่นั้นถูกอัพเดต การทำเครื่องหมายคอลัมน์ที่คำนวณเป็น PERSISTED อนุญาตให้สร้างดัชนีบนคอลัมน์ที่คำนวณได้ซึ่งกำหนดไว้ แต่ไม่แม่นยำ สำหรับข้อมูลเพิ่มเติมดูดัชนีในคอลัมน์ที่คำนวณ …

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

2
ค่าใช้จ่ายในการอัปเดตคอลัมน์ทั้งหมดคืออะไรแม้แต่คนที่ไม่ได้เปลี่ยนแปลง [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา เมื่อพูดถึงการอัพเดตแถวเครื่องมือ ORM จำนวนมากออกคำสั่ง UPDATE ที่ตั้งค่าทุกคอลัมน์ที่เกี่ยวข้องกับเอนทิตีนั้น ข้อดีคือคุณสามารถแบทช์ข้อความสั่งการอัพเดทได้อย่างง่ายดายเนื่องจากUPDATEข้อความนั้นเหมือนกันไม่ว่าคุณจะเปลี่ยนเอนทิตีแอตทริบิวต์ใด ยิ่งไปกว่านั้นคุณยังสามารถใช้การแคชคำสั่งฝั่งเซิร์ฟเวอร์และไคลเอนต์ได้เช่นกัน ดังนั้นถ้าฉันโหลดเอนทิตีและตั้งค่าคุณสมบัติเดียวเท่านั้น: Post post = entityManager.find(Post.class, 1L); post.setScore(12); คอลัมน์ทั้งหมดจะมีการเปลี่ยนแปลง: UPDATE post SET score = 12, title = 'High-Performance Java Persistence' WHERE id = 1 ทีนี้สมมติว่าเรามีดัชนีในtitleคุณสมบัติเช่นกันฐานข้อมูลไม่ควรตระหนักว่ามูลค่าไม่เปลี่ยนแปลง ในบทความนี้ Markus Winand พูดว่า: การอัปเดตในคอลัมน์ทั้งหมดแสดงรูปแบบเดียวกับที่เราสังเกตเห็นแล้วในส่วนก่อนหน้า: เวลาตอบสนองจะเพิ่มขึ้นพร้อมกับดัชนีเพิ่มเติมแต่ละรายการ ฉันสงสัยว่าทำไมโอเวอร์เฮดนี้เนื่องจากฐานข้อมูลโหลดหน้าข้อมูลที่เกี่ยวข้องจากดิสก์ไปยังหน่วยความจำและเพื่อให้สามารถทราบได้ว่าค่าคอลัมน์จำเป็นต้องเปลี่ยนหรือไม่ แม้สำหรับดัชนีก็ไม่ต้องปรับสมดุลอะไรเลยเนื่องจากค่าดัชนีไม่เปลี่ยนแปลงสำหรับคอลัมน์ที่ไม่ได้เปลี่ยนแปลง แต่รวมอยู่ในการอัพเดท เป็นดัชนี B + …

1
ทำไมไม่สร้างดัชนีใหม่ด้วยจำนวนหน้า <1,000
ฉันใช้สคริปต์ Ola Hallengrens สำหรับการบำรุงรักษาดัชนี ก่อนที่ฉันจะทำอย่างนั้นฉันใช้แบบสอบถามต่อไปนี้เพื่อดูว่าดัชนีใดที่มีการแยกส่วนมากที่สุด: SELECT dbschemas.[name] as 'Schema', dbtables.[name] as 'Table', dbindexes.[name] as 'Index', indexstats.avg_fragmentation_in_percent, indexstats.page_count FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id] INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id] INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = …

2
ขั้นตอนการจัดเก็บกลางเพื่อดำเนินการในบริบทฐานข้อมูลการโทร
ฉันกำลังทำงานกับโซลูชันการบำรุงรักษาที่กำหนดเองโดยใช้sys.dm_db_index_physical_statsมุมมอง ฉันมีมันถูกอ้างอิงจากขั้นตอนการจัดเก็บ ตอนนี้เมื่อโพรซีเดอร์ที่เก็บรันบนหนึ่งในฐานข้อมูลของฉันมันทำสิ่งที่ฉันต้องการให้ทำและดึงรายการของระเบียนทั้งหมดที่เกี่ยวข้องกับฐานข้อมูลใด ๆ ลง เมื่อฉันวางไว้ในฐานข้อมูลอื่นมันจะดึงรายการทั้งหมดที่เกี่ยวข้องกับฐานข้อมูลนั้นลง ตัวอย่างเช่น (รหัสที่ด้านล่าง): การค้นหาทำงานกับฐานข้อมูล 6 แสดงข้อมูล [ร้องขอ] สำหรับฐานข้อมูล 1-10 เคียวรีรันกับฐานข้อมูล 3 แสดงข้อมูล [ร้องขอ] สำหรับฐานข้อมูล 3 เท่านั้น เหตุผลที่ฉันต้องการขั้นตอนนี้โดยเฉพาะในฐานข้อมูลสามเป็นเพราะฉันต้องการเก็บวัตถุการบำรุงรักษาทั้งหมดในฐานข้อมูลเดียวกัน ฉันต้องการให้งานนี้อยู่ในฐานข้อมูลการบำรุงรักษาและทำงานราวกับว่าอยู่ในฐานข้อมูลแอปพลิเคชันนั้น รหัส: ALTER PROCEDURE [dbo].[GetFragStats] @databaseName NVARCHAR(64) = NULL ,@tableName NVARCHAR(64) = NULL ,@indexID INT = NULL ,@partNumber INT = NULL ,@Mode NVARCHAR(64) = 'DETAILED' AS BEGIN SET …

1
เมื่อใดที่คุณควรระบุ PAD_INDEX
ดังนั้นคุณสามารถใช้FILLFACTORเพื่อเว้นช่องว่างในหน้าดัชนีลีฟ การระบุPAD_INDEXยังเว้นช่องว่างในโหนดกลาง สถานการณ์ใดที่คุณควรระบุPAD_INDEXและมีประโยชน์อะไรบ้างต่อดัชนี

2
ไม่มีการใช้ดัชนีคีย์หลักที่มี DATETIME เนื่องจากส่วนแรกของคีย์ผสม
ฉันมีปัญหากับการทำดัชนีเวลา (หรือแม้กระทั่งวันที่) เป็นส่วนแรกของคีย์หลักของฉัน ฉันใช้ MySQL 5.5 นี่คือสองตารางของฉัน: -- This is my standard table with dateDim as a dateTime CREATE TABLE `stats` ( `dateDim` datetime NOT NULL, `accountDim` mediumint(8) unsigned NOT NULL, `execCodeDim` smallint(5) unsigned NOT NULL, `operationTypeDim` tinyint(3) unsigned NOT NULL, `junkDim` tinyint(3) unsigned NOT NULL, `ipCountryDim` smallint(5) unsigned NOT …

3
สุดยอด MyISAM และ InnoDB
เป็นไปได้หรือไม่ที่จะทำให้ InnoDB ใช้ดัชนีเช่นเดียวกับ MyISAM แทนที่จะเป็นดัชนีแบบคลัสเตอร์เนื่องจากข้อ จำกัด ของ RAM ในขณะที่รับประโยชน์จากประสิทธิภาพการทำงานพร้อมกัน?

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

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