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

กระบวนการพิจารณาดัชนีที่มีประโยชน์และไม่ได้

3
ดัชนีคอมโพสิตยังดีสำหรับการค้นหาในเขตข้อมูลแรกหรือไม่
สมมติว่าผมมีตารางที่มีสาขาและA Bฉันจะทำให้คำสั่งปกติA+ ดังนั้นฉันสร้างดัชนีคอมโพสิตในB (A,B)คำสั่งในการค้นหาAจะได้รับการปรับให้เหมาะสมอย่างเต็มที่โดยดัชนีคอมโพสิตหรือไม่ นอกจากนี้ผมสร้างดัชนีในAแต่ Postgres Aยังคงใช้ดัชนีคอมโพสิตสำหรับการค้นหาเท่านั้น หากคำตอบก่อนหน้าเป็นบวกฉันคิดว่ามันไม่สำคัญ แต่ทำไมมันถึงเลือกดัชนีคอมโพสิตตามค่าเริ่มต้นหากมีAดัชนีเดียว

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

1
ฉันควรใช้ดัชนีฟิลด์เดียวหลายดัชนีแทนที่จะเป็นดัชนีหลายคอลัมน์ที่เฉพาะเจาะจงหรือไม่
คำถามนี้เกี่ยวกับประสิทธิผลของเทคนิคการทำดัชนี SQL Server ฉันคิดว่าเป็นที่รู้จักกันในชื่อ "จุดตัดดัชนี" ฉันกำลังทำงานกับแอปพลิเคชัน SQL Server (2008) ที่มีอยู่ซึ่งมีปัญหาเรื่องประสิทธิภาพและความเสถียรหลายประการ นักพัฒนาทำสิ่งแปลก ๆ ด้วยการจัดทำดัชนี ฉันไม่สามารถรับข้อสรุปมาตรฐานเกี่ยวกับปัญหาเหล่านี้ได้ฉันไม่สามารถหาเอกสารที่ดีเกี่ยวกับ internets ได้ มีคอลัมน์ที่ค้นหาได้จำนวนมากในตาราง นักพัฒนาสร้างดัชนีคอลัมน์เดียวในแต่ละคอลัมน์ที่ค้นหาได้ ทฤษฎีคือ SQL Server จะสามารถรวม (ตัดกัน) แต่ละดัชนีเหล่านี้เพื่อเข้าถึงตารางอย่างมีประสิทธิภาพในสถานการณ์ส่วนใหญ่ นี่คือตัวอย่างที่ง่าย (ตารางจริงมีเขตข้อมูลเพิ่มเติม): CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] [varchar](2000) NOT NULL, ... CREATE NONCLUSTERED INDEX …



2
ดัชนีหลายคอลัมน์และประสิทธิภาพ
ฉันมีตารางที่มีดัชนีหลายคอลัมน์และฉันมีข้อสงสัยเกี่ยวกับการเรียงลำดับที่เหมาะสมของดัชนีเพื่อให้ได้ประสิทธิภาพสูงสุดในการสืบค้น สถานการณ์: PostgreSQL 8.4 ตารางที่มีประมาณหนึ่งล้านแถว ค่าในคอลัมน์c1สามารถมีประมาณ100 ค่าที่แตกต่างกัน เราสามารถสันนิษฐานได้ว่าค่ามีการกระจายอย่างเท่าเทียมกันดังนั้นเราจึงมีประมาณ 10,000 แถวสำหรับทุกค่าที่เป็นไปได้ คอลัมน์c2สามารถมี1,000 ค่าที่แตกต่าง เรามี 1,000 แถวสำหรับทุกค่าที่เป็นไปได้ เมื่อค้นหาข้อมูลเงื่อนไขจะมีค่าสำหรับคอลัมน์สองคอลัมน์เหล่านี้เสมอดังนั้นตารางจะมีดัชนีหลายคอลัมน์ซึ่งรวม c1 และ c2 ฉันได้อ่านเกี่ยวกับความสำคัญของการจัดเรียงคอลัมน์ในดัชนีหลายคอลัมน์อย่างถูกต้องหากคุณมีข้อความค้นหาที่ใช้เพียงคอลัมน์เดียวในการกรอง นี่ไม่ใช่กรณีในสถานการณ์ของเรา คำถามของฉันคือคำถามนี้: จากข้อเท็จจริงที่ว่าหนึ่งในตัวกรองเลือกชุดข้อมูลที่เล็กกว่ามากฉันจะปรับปรุงประสิทธิภาพได้ไหมถ้าดัชนีตัวแรกเป็นตัวเลือกที่เลือกได้มากที่สุด ฉันไม่เคยพิจารณาคำถามนี้จนกระทั่งเห็นกราฟิกจากบทความที่อ้างอิง: ภาพที่นำมาจากบทความที่อ้างอิงเกี่ยวกับดัชนีหลายคอลัมน์ แบบสอบถามใช้ค่าจากสองคอลัมน์ในการกรอง ฉันไม่มีข้อความค้นหาที่ใช้เพียงหนึ่งคอลัมน์ในการกรอง พวกเขาทั้งหมดคือ: WHERE c1=@ParameterA AND c2=@ParameterB. นอกจากนี้ยังมีเงื่อนไขเช่นนี้:WHERE c1 = "abc" AND c2 LIKE "ab%"

2
จะรู้ได้อย่างไรว่าเมื่อไหร่ที่ฉันมีดัชนีมากเกินไป
ใช้ Microsoft SQL Server Profiler ทุกครั้งจากนั้นแนะนำฉันด้วยดัชนีและสถิติใหม่ ๆ ที่จะสร้าง ("... 97% การปรับปรุงโดยประมาณ ... ") จากความเข้าใจของฉันทุกดัชนีเพิ่มสามารถทำให้SELECTแบบสอบถามSQL ได้เร็วขึ้น แต่ยังUPDATEหรือINSERTแบบสอบถามช้าลงเนื่องจากดัชนีจะต้องมีการปรับ สิ่งที่ฉันสงสัยคือเมื่อฉันมีดัชนี / สถิติ "มากเกินไป" อาจจะไม่มีคำตอบที่ชัดเจนเกี่ยวกับเรื่องนี้ แต่บางกฎของหัวแม่มือ

1
ดัชนี: จำนวนเต็มกับประสิทธิภาพของสตริงถ้าจำนวนโหนดเท่ากัน
ฉันกำลังพัฒนาแอพพลิเคชั่นใน Ruby on Rails ด้วยฐานข้อมูล PostgreSQL (9.4) สำหรับกรณีการใช้งานของฉันคอลัมน์ในตารางจะถูกค้นหาบ่อยมากเนื่องจากทั้งจุดของแอปพลิเคชันกำลังค้นหาแอตทริบิวต์ที่เฉพาะเจาะจงมากในแบบจำลอง ฉันกำลังตัดสินใจว่าจะใช้integerชนิดหรือเพียงแค่ใช้ประเภทสตริงทั่วไป (เช่นcharacter varying(255), ซึ่งเป็นค่าเริ่มต้นใน Rails ) สำหรับคอลัมน์ที่เป็นผมไม่แน่ใจว่าสิ่งที่แตกต่างของประสิทธิภาพการทำงานจะอยู่ในดัชนี คอลัมน์เหล่านี้เป็น enums มีขนาดคงที่สำหรับจำนวนค่าที่เป็นไปได้ที่สามารถมีได้ ส่วนใหญ่ความยาว enum ไม่เกิน 5 หมายถึงดัชนีจะมีมากขึ้นหรือน้อยคงที่ตลอดอายุการใช้งานของโปรแกรม ; ดังนั้นจำนวนเต็มและดัชนีสตริงจะเหมือนกันในจำนวนโหนด อย่างไรก็ตามสตริงที่จะทำดัชนีอาจมีความยาวประมาณ 20 ตัวอักษรซึ่งในหน่วยความจำประมาณ 5x ของจำนวนเต็ม (ถ้าจำนวนเต็ม 4 ไบต์และสตริงนั้นเป็น ASCII บริสุทธิ์ที่ 1 ไบต์ต่อตัวอักษรดังนั้นสิ่งนี้จะเก็บไว้) ฉันไม่รู้ว่าเอ็นจิ้นฐานข้อมูลทำการค้นหาดัชนีอย่างไร แต่ถ้ามันจำเป็นต้อง "สแกน" สตริงจนกว่าจะตรงกันทั้งหมดดังนั้นในสาระสำคัญซึ่งหมายความว่าการค้นหาสตริงจะช้ากว่าการค้นหาจำนวนเต็ม 5 เท่า "สแกน" จนกระทั่งตรงกับการค้นหาจำนวนเต็มจะเป็น 4 ไบต์แทน 20 นี่คือสิ่งที่ฉันจินตนาการ ค่าการค้นหาคือ …

4
หากฐานข้อมูลมีการแทรกเพียงครั้งเดียวมันจะไม่ดีที่จะทำดัชนีชุดค่าผสมของคอลัมน์ที่เป็นไปได้หรือไม่?
ฉันกำลังทำงานกับระบบการรายงานที่จะต้องใช้แบบสอบถามที่มีขนาดใหญ่ แต่ขึ้นอยู่กับฐานข้อมูลที่กรอกเพียงครั้งเดียว ระบบการจัดการฐานข้อมูลคือ Microsoft SQL Server 2017 อาจมีวิธีที่ดีกว่าในการออกแบบระบบเช่นนี้ ในทางทฤษฎีการพูด: หากเรามีฐานข้อมูลขนาดใหญ่มาก (150M + แถวในหลายตาราง) และเราสามารถสรุปได้ว่าฐานข้อมูลจะถูกบรรจุครั้งเดียว การทำดัชนีทุกชุดคอลัมน์ที่เป็นไปได้มีผลกระทบด้านลบต่อแบบสอบถามแบบใช้เลือกข้อมูลหรือไม่

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 …

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
ทำไมดัชนีที่ถูกกรองในค่า IS NULL ไม่ถูกใช้
สมมติว่าเรามีคำจำกัดความของตารางดังนี้: CREATE TABLE MyTab ( ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY ,GroupByColumn NVARCHAR(10) NOT NULL ,WhereColumn DATETIME NULL ) และดัชนีที่ไม่ได้ทำคลัสเตอร์ที่กรองแล้วเช่นนี้: CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab (GroupByColumn) WHERE (WhereColumn IS NULL) เหตุใดดัชนีนี้จึงไม่ "ครอบคลุม" สำหรับคำค้นหานี้: SELECT GroupByColumn ,COUNT(*) FROM MyTab WHERE WhereColumn IS NULL GROUP BY GroupByColumn ฉันได้รับแผนปฏิบัติการนี้แล้ว: KeyLookup ใช้สำหรับกริยาที่ …

2
ตาราง mysql ที่มีประสิทธิภาพ / การออกแบบดัชนีสำหรับ 35 ล้านแถว + ตารางโดยมี 200+ คอลัมน์ที่เกี่ยวข้อง (สองเท่า) การรวมกันใด ๆ ที่อาจมีการสอบถาม
ฉันกำลังมองหาคำแนะนำในการออกแบบตาราง / ดัชนีสำหรับสถานการณ์ต่อไปนี้: ฉันมีตารางขนาดใหญ่ (ข้อมูลประวัติราคาหุ้น InnoDB 35 ล้านแถวและเพิ่มขึ้น) ด้วยคีย์หลักผสม (assetid (int) วันที่ (วันที่) นอกเหนือจากข้อมูลการกำหนดราคาแล้วฉันมี 200 ค่าสองเท่าที่จำเป็นต้องสอดคล้องกับแต่ละระเบียน CREATE TABLE `mytable` ( `assetid` int(11) NOT NULL, `date` date NOT NULL, `close` double NOT NULL, `f1` double DEFAULT NULL, `f2` double DEFAULT NULL, `f3` double DEFAULT NULL, `f4` double DEFAULT NULL, ... skip …

3
ทำไม SQL Server จะไม่สนใจดัชนี
ผมมีตารางCustPassMasterที่มี 16 คอลัมน์ในนั้นซึ่งเป็นหนึ่งและฉันสร้างดัชนีCustNum varchar(8) IX_dbo_CustPassMaster_CustNumเมื่อฉันเรียกใช้SELECTคำสั่งของฉัน: SELECT * FROM dbo.CustPassMaster WHERE CustNum = '12345678' จะละเว้นดัชนีอย่างสมบูรณ์ สับสนนี้ฉันเป็นฉันมีตารางอีกCustDataMasterด้วยวิธีการคอลัมน์อื่น ๆ (55) CustNum varchar(8)ซึ่งหนึ่งในนั้นคือ ฉันสร้างดัชนีในคอลัมน์นี้ ( IX_dbo_CustDataMaster_CustNum) ในตารางนี้และใช้แบบสอบถามเดียวกันจริง: SELECT * FROM dbo.CustDataMaster WHERE CustNum = '12345678' และใช้ดัชนีที่ฉันสร้างขึ้น มีเหตุผลเฉพาะที่อยู่เบื้องหลังสิ่งนี้หรือไม่? ทำไมมันจะใช้ดัชนีจากCustDataMasterแต่ไม่จากCustPassMaster? มันเป็นเพราะการนับคอลัมน์ต่ำ? แบบสอบถามแรกส่งคืน 66 แถว สำหรับแถวที่สองจะส่งคืน 1 แถว นอกจากนี้หมายเหตุเพิ่มเติม: CustPassMasterมี 4991 บันทึกและCustDataMasterมี 5376 บันทึก นี่อาจเป็นเหตุผลที่ละเลยดัชนีหรือไม่ CustPassMasterยังมีระเบียนที่ซ้ำกันซึ่งมีCustNumค่าเหมือนกันเช่นกัน นี่เป็นปัจจัยอื่นหรือไม่ …

2
การแคชดัชนี PostgreSQL
ฉันมีปัญหาในการค้นหาคำอธิบาย 'lay' ของวิธีการจัดทำดัชนีแคชใน PostgreSQL ดังนั้นฉันต้องการตรวจสอบความเป็นจริงของสมมติฐานเหล่านี้ทั้งหมดหรือทั้งหมด: ดัชนี PostgreSQL เช่นแถวอยู่บนดิสก์ แต่อาจถูกแคช ดัชนีอาจอยู่ในแคชทั้งหมดหรือไม่ทั้งหมด ไม่ว่าจะเป็นแคชหรือไม่ขึ้นอยู่กับความถี่ในการใช้งาน (ตามที่กำหนดโดยตัววางแผนคิวรี) ด้วยเหตุนี้ดัชนี 'สมเหตุสมผล' ส่วนใหญ่จึงจะอยู่ในแคชตลอดเวลา ดัชนีอยู่ในแคชเดียวกัน ( buffer cache?) เป็นแถวดังนั้นพื้นที่แคชที่ใช้โดยดัชนีจะไม่สามารถใช้ได้กับแถว แรงจูงใจของฉันสำหรับการทำความเข้าใจนี้ตามมาจากคำถามอื่นที่ฉันถามว่ามีข้อเสนอแนะว่าสามารถใช้ดัชนีบางส่วนในตารางซึ่งข้อมูลส่วนใหญ่จะไม่สามารถเข้าถึงได้ ก่อนดำเนินการนี้ฉันต้องการให้ชัดเจนว่าการใช้ดัชนีบางส่วนทำให้ได้เปรียบสองประการ: เราลดขนาดของดัชนีในแคชเพิ่มพื้นที่ว่างสำหรับแถวในแคช เราลดขนาดของ B-Tree ส่งผลให้เกิดการตอบแบบสอบถามที่รวดเร็วขึ้น

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