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

ฉันกำลังปรับปรุงการค้นหาให้ดีที่สุด สำหรับแบบสอบถามด้านล่าง SET STATISTICS IO ON; DECLARE @OrderStartDate DATETIME2 = '27 feb 2016'; DECLARE @OrderEndDate DATETIME2 = '28 feb 2016'; SELECT o.strBxOrderNo , o.sintOrderStatusID , o.sintOrderChannelID , o.sintOrderTypeID , o.sdtmOrdCreated , o.sintMarketID , o.strOrderKey , o.strOfferCode , o.strCurrencyCode , o.decBCShipFullPrice , o.decBCShipFinal , o.decBCShipTax , o.decBCTotalAmount , o.decWrittenTotalAmount , o.decBCWrittenTotalAmount …

15 sql-server  query-performance  sql-server-2014  optimization  index-tuning 

คำถามนี้เป็นคำถามเกี่ยวกับประสิทธิภาพของดัชนี SQL Server กับvarchar(2000)เป็นINCLUDEในดัชนีที่ครอบคลุม ฉันพยายามปรับปรุงประสิทธิภาพในแอปพลิเคชันฐานข้อมูลที่ช้าและไม่เสถียร ในบางกรณีข้อมูลที่มีการเข้าถึงผ่านสตริง varchar ขนาดใหญ่ที่มีการค้นหารวมทั้งการดำเนินสตริง multple เหมือนSUBSTRING(), และSPACE() DATALENGTH()นี่คือตัวอย่างที่ง่ายของการเข้าถึง update fattable set col3 = SUBSTRING(col3,1,10) + '*' + SUBSTRING(col3,12,DATALENGTH(col3)-12) from fattable where substring(col3,10,1) = 'A' and col2 = 2 สคีมามีลักษณะดังนี้: CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] …

15 sql-server  sql-server-2008  performance  index-tuning 

ฉันได้มีการถกเถียงอย่างต่อเนื่องกับนักพัฒนาหลายคนในสำนักงานของฉันเกี่ยวกับค่าใช้จ่ายของดัชนีและความเป็นเอกลักษณ์หรือไม่นั้นมีประโยชน์หรือมีค่าใช้จ่ายสูง (อาจเป็นได้ทั้งสองอย่าง) ปมของปัญหาคือทรัพยากรการแข่งขันของเรา พื้นหลัง ก่อนหน้านี้ฉันได้อ่านการสนทนาที่ระบุว่าUniqueดัชนีนั้นไม่มีค่าใช้จ่ายเพิ่มเติมในการบำรุงรักษาเนื่องจากการInsertดำเนินการโดยปริยายจะตรวจสอบว่าตรงกับต้นไม้ B หรือไม่และหากพบซ้ำในดัชนีที่ไม่ซ้ำใคร จุดสิ้นสุดของคีย์ แต่อย่างอื่นแทรกโดยตรง ในลำดับเหตุการณ์นี้Uniqueดัชนีไม่มีค่าใช้จ่ายเพิ่มเติม ผู้ร่วมงานของฉันต่อสู้กับแถลงการณ์นี้โดยกล่าวว่าการUniqueบังคับใช้เป็นการดำเนินการครั้งที่สองหลังจากการค้นหาตำแหน่งใหม่ในต้นไม้ B และทำให้ค่าใช้จ่ายในการบำรุงรักษาสูงกว่าดัชนีที่ไม่ซ้ำใคร ที่แย่ที่สุดฉันได้เห็นตารางที่มีคอลัมน์ข้อมูลประจำตัว (ไม่ซ้ำกันโดยเนื้อแท้) นั่นคือคีย์การทำคลัสเตอร์ของตาราง แต่ระบุไว้อย่างชัดเจนว่าไม่ซ้ำกัน ในอีกด้านหนึ่งของความเลวร้ายที่สุดคือการครอบงำจิตใจของฉันด้วยเอกลักษณ์และดัชนีทั้งหมดจะถูกสร้างขึ้นเป็นเอกลักษณ์และเมื่อไม่สามารถกำหนดความสัมพันธ์ที่ไม่ซ้ำกันอย่างชัดเจนกับดัชนีฉันผนวก PK ของตารางไปยังจุดสิ้นสุดของดัชนีเพื่อรับรอง รับประกันความเป็นเอกลักษณ์ ฉันมีส่วนร่วมในการตรวจสอบโค้ดสำหรับทีม dev บ่อยครั้งและฉันต้องสามารถให้แนวทางทั่วไปเพื่อให้พวกเขาทำตาม ใช่ทุกดัชนีควรได้รับการประเมิน แต่เมื่อคุณมีเซิร์ฟเวอร์ห้าตัวที่มีตารางนับพันแต่ละตัวและมากถึงยี่สิบดัชนีในตารางคุณจะต้องสามารถใช้กฎง่าย ๆ เพื่อรับประกันคุณภาพในระดับหนึ่ง คำถาม เอกลักษณ์มีค่าใช้จ่ายเพิ่มเติมที่ส่วนท้ายของการInsertเปรียบเทียบกับค่าใช้จ่ายในการบำรุงรักษาดัชนีที่ไม่ซ้ำหรือไม่? ประการที่สองมีอะไรผิดปกติในการผนวกคีย์หลักของตารางต่อท้ายดัชนีเพื่อให้แน่ใจว่ามีเอกลักษณ์? ตัวอย่างคำจำกัดความของตาราง create table #test_index ( id int not null identity(1, 1), dt datetime not null default(current_timestamp), val varchar(100) not …

14 sql-server  index-tuning  database-internals  unique-constraint 

ฉันต้องการค้นหาแบบเร็วโดยดูจากว่ามีสองคอลัมน์เท่ากัน ฉันพยายามใช้คอลัมน์ที่คำนวณด้วยดัชนี แต่ SQL Server ดูเหมือนจะไม่ใช้มัน ถ้าฉันใช้คอลัมน์บิตที่มีค่าคงที่กับดัชนีฉันจะได้ดัชนีที่ต้องการ ดูเหมือนว่ามีคำถามอื่น ๆ เช่นนี้อยู่ที่นั่น แต่ไม่มีใครสนใจว่าทำไมดัชนีจะไม่ถูกใช้ ตารางทดสอบ: CREATE TABLE dbo.Diffs ( Id int NOT NULL IDENTITY (1, 1), DataA int NULL, DataB int NULL, DiffPersisted AS isnull(convert(bit, case when [DataA] is null and [DataB] is not null then 1 when [DataA] <> [DataB] then 1 …

14 sql-server  index  index-tuning  computed-column 

ฉันมีตารางที่มีจำนวนมากแทรกการตั้งค่าหนึ่งของฟิลด์ ( uploaded_at) NULLเพื่อ จากนั้นภารกิจตามระยะเวลาจะเลือกสิ่งอันดับทั้งหมดWHERE uploaded_at IS NULLประมวลผลและอัปเดตตั้งค่าuploaded_atเป็นวันที่ปัจจุบัน ฉันควรจัดทำดัชนีตารางอย่างไร ฉันเข้าใจว่าฉันควรใช้ดัชนีบางส่วนเช่น: CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL หรือว่าอย่างนั้น ฉันบิตสับสน NULLแต่ถ้ามันเป็นสิ่งที่ถูกต้องเพื่อดัชนีในเขตข้อมูลที่อยู่เสมอ หรือถ้ามันถูกต้องที่จะใช้ดัชนี b-tree Hash ดูเหมือนเป็นความคิดที่ดีกว่า แต่ล้าสมัยและไม่ได้รับการจำลองแบบผ่านการสตรีมการจำลองแบบ hot-standby คำแนะนำใด ๆ ที่จะได้รับการชื่นชมอย่างมาก ฉันได้ทดลองเล็กน้อยด้วยดัชนีต่อไปนี้: "foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL "foo_part_id" btree (id) WHERE uploaded_at IS NULL และตัววางแผนแบบสอบถามดูเหมือนว่าจะเลือกfoo_partดัชนีเสมอ explain analyseยังให้ผลลัพธ์ที่ดีขึ้นเล็กน้อยสำหรับfoo_partดัชนี: …

14 postgresql  index  index-tuning  null 

ฉันมีโต๊ะ | base_schedule_line_items | สร้างตารางbase_schedule_line_items( idint (10) unsigned NOT NULL AUTO_INCREMENT, installmentint (10) unsigned NOT NULL, on_dateวันที่ NOT NULL, actual_dateวันที่ DEFAULT NULL, payment_typeint (11) NOT NULL, scheduled_principal_outstandingทศนิยม (65,0) NOT NULL, scheduled_principal_dueทศนิยม (65,0) ไม่เป็น NULL, scheduled_interest_outstandingทศนิยม (65,0) ไม่เป็น NULL, scheduled_interest_dueทศนิยม (65,0) ไม่เป็น NULL, currencyint (11) ไม่เป็น NULL, วันที่และเวลา updated_atไม่เป็นค่าเริ่มต้น '2013-01-06 14:29:16', …

13 mysql  index  index-tuning 

นี่เป็นสถานการณ์ที่แปลก แต่ฉันหวังว่าบางคนจะมีคำตอบ ในบางช่วงการแก้ไขปัญหาประสิทธิภาพการทำงานของเราได้เพิ่ม nonclustered INDEX sp_BlitzIndexในตารางตามที่ได้รับการร้องขอจาก เราตรวจสอบการใช้งานในวันถัดไปและพบว่ามีการอ่าน0 ครั้ง (การสแกน 0 ครั้ง / การค้นหาการค้นหาเดี่ยว 0 ครั้ง ) ดังนั้นเราจึงปิดการใช้งาน ในนาทีถัดไปเราได้รับการร้องเรียนเกี่ยวกับแอพพลิเคชั่นช้า (ปัญหาประสิทธิภาพ) ที่เราพยายามตรวจสอบและแก้ไขในตอนแรกเมื่อเราเพิ่ม INDEX ทีนี้ฉันรู้แล้วในทางทฤษฎีฟังดูเป็นเรื่องบังเอิญอย่างแท้จริง ดัชนีถูกสรรพสิ่ง, วัด, ที่ไม่ได้ใช้ ปิดการใช้งานไม่ควรทำให้ประสิทธิภาพการทำงานของแบบสอบถามลดลง แต่มันเกือบจะบังเอิญเกินไป คำถาม ดังนั้นคำถามของฉันก็เพียงพอแล้ว: มันเป็นไปได้ทุกที่ , ว่า nonclustered INDEX ซึ่งมีการใช้งานสถิติ (จาก DMVs / การsp_BlitzIndex) แสดงการใช้งาน NO ยังคงได้รับการช่วยให้ประสิทธิภาพการค้นหาบนโต๊ะอย่างใดได้รับผลกระทบหรือไม่

13 sql-server  database-design  index-tuning  sql-server-2016  nonclustered-index 

นักพัฒนาของฉันได้ติดตั้งแอปพลิเคชันของพวกเขาเพื่อใช้ GUID เป็น PK สำหรับตารางทั้งหมดของพวกเขาและโดยค่าเริ่มต้น SQL Server ได้ตั้งค่าดัชนีคลัสเตอร์บน PK เหล่านี้ ระบบนี้ค่อนข้างใหม่และตารางที่ใหญ่ที่สุดของเรามีมากกว่าหนึ่งล้านแถว แต่เรากำลังดูการจัดทำดัชนีของเราและต้องการให้สามารถปรับขนาดได้อย่างรวดเร็วเนื่องจากอาจมีความจำเป็นในอนาคตอันใกล้ ดังนั้นความโน้มเอียงแรกของฉันคือการย้ายดัชนีคลัสเตอร์ไปยังเขตข้อมูลที่สร้างขึ้นซึ่งเป็นตัวแทนขนาดใหญ่ของ DateTime อย่างไรก็ตามวิธีเดียวที่ฉันสามารถสร้าง CX ที่ไม่เหมือนใครคือการรวมคอลัมน์ GUID ใน CX นี้ แต่เรียงลำดับโดยสร้างขึ้นก่อน นี่จะทำให้คีย์การทำคลัสเตอร์กว้างเกินไปและจะเพิ่มประสิทธิภาพสำหรับการเขียนหรือไม่ การอ่านมีความสำคัญเช่นกัน แต่การเขียนอาจเป็นปัญหาที่ใหญ่กว่าในตอนนี้

13 sql-server  index-tuning  clustered-index  uniqueidentifier 

SQL Server 2014 Standard Edition ฉันต้องการค้นหาจำนวนเที่ยวบินที่ไปและกลับจากบางเมืองในบางเดือน เช่น select count(*) from flights where flightTo_AirportCode = 'aaaa' and flightFrom_Airportcode = 'bbbb' and flightdate < '2016-04-01' and flightdate > '2016-02-28' ; ตารางสคีมาอยู่ด้านล่าง ฉันพยายามที่จะประเมินว่าดัชนี modelA หรือ index modelB (ด้านล่าง) เป็นที่นิยมหรือไม่ (ใช้เวลาหลายชั่วโมงในการสร้างดัชนีและพื้นที่ดิสก์อนุญาตให้มีอยู่ครั้งละหนึ่งรายการเท่านั้นดังนั้นฉันจึงพยายามมองก่อนที่จะกระโดด) จากประสบการณ์ของฉันทั้งดัชนีจะทำ ฉันถูกไหม? create index [modelA] on flights (flightTo_AirportCode, flightFrom_AirportCode, flightDate) create index [modelB] …

11 sql-server  sql-server-2014  index-tuning 

ฉันกำลังเผชิญหน้ากับการหยุดชะงักที่เกิดขึ้นอีกครั้งหนึ่งในนั้นคือ Keylock และมีการสืบค้น SELECT พร้อมคำใบ้ XLOCK ที่กลายเป็นเหยื่อการหยุดชะงัก คำสั่งอื่น ๆ คือการแทรกลงในหนึ่งในตารางที่เป็นส่วนหนึ่งของมุมมองของแบบสอบถามแรก ดู: create view dbo.viewE as select * from dbo.E where myValue > 13000 เลือกคำค้นหา: select * from dbo.viewE with (XLOCK) where A > GETUTCDATE() คำสั่ง INSERT: INSERT INTO [dbo].[E] (myValue,A) VALUES (10,GetDate()) ตารางต้นแบบ dbo.E มีพื้นที่ประมาณ 3 ล้านแถวในประมาณ 20 คอลัมน์บางส่วนเป็น ntext …

11 sql-server  sql-server-2008-r2  index-tuning  locking  deadlock 

ฉันกำลังพยายามติดตั้งมุมมองที่จัดทำดัชนีไว้ในสถานการณ์จำลองต่อไปนี้เพื่อให้แบบสอบถามต่อไปนี้ทำงานได้โดยไม่สแกนดัชนีคลัสเตอร์ เมื่อใดก็ตามที่ฉันสร้างมุมมองดัชนีสำหรับแบบสอบถามนี้แล้วใช้มันดูเหมือนว่าจะไม่สนใจดัชนีใด ๆ ที่ฉันวางไว้: -- +++ THE QUERY THAT I WANT TO IMPROVE PERFORMANCE-WISE +++ SELECT TOP 1 * FROM dbo.TB_test1 t1 INNER JOIN dbo.TB_test2 t2 ON t1.PK_ID1 = t2.FK_ID1 ORDER BY t1.somethingelse1 ,t2.somethingelse2; GO การตั้งค่าตารางมีดังนี้: สองตาราง พวกเขาจะเข้าร่วมโดยการเข้าร่วมภายในโดยแบบสอบถามด้านบน และเรียงลำดับโดยคอลัมน์จากคอลัมน์แรกจากนั้นคอลัมน์จากตารางที่สองโดยแบบสอบถามด้านบน เลือก TOP 1 เท่านั้น (ในสคริปต์ด้านล่างมีบางบรรทัดเพื่อสร้างข้อมูลทดสอบในกรณีที่ช่วยทำให้เกิดปัญหา) -- +++ TABLE SETUP +++ CREATE …

11 sql-server  sql-server-2008  index  index-tuning  materialized-view 

ฉันสร้างดัชนีต่อไปนี้บนตารางในฐานข้อมูลของฉัน: CREATE INDEX [idx_index1] on [table1] (col1, col2, col3) เซิร์ฟเวอร์กำลังแนะนำดัชนี 'ขาดหายไป' ต่อไปนี้: CREATE INDEX [idx_index2] on [table1] (col1, col2) INCLUDE (col3, col4, col5, col6....) ดูเหมือนว่าฉันมีเหตุผลที่จะแก้ไขคำจำกัดความดัชนีที่มีอยู่เพื่อรวมคอลัมน์ที่แนะนำแทนที่จะสร้างดัชนีใหม่ที่ต้องได้รับการบำรุงรักษา แบบสอบถามที่เลือกบน col1 และ col2 สามารถใช้ index1 ได้อย่างมีประสิทธิภาพเท่ากับ index2 ฉันถูกต้องหรือว่าฉันขาดอะไรไป

11 sql-server  sql-server-2008-r2  index  index-tuning 

จากแบบสอบถามนี้ถ้าฉันเห็นจำนวนการอ่านน้อย (ใกล้เคียงกับ 0 หรือ 0, เช่น 1 หรือ 2) และการอัปเดตผู้ใช้จำนวนมากหรือปานกลาง (ฉันไม่สามารถค้นหาแทรกหรือลบด้วยแบบสอบถามนี้) จำนวนแถวขนาดใหญ่ฉันควรลบดัชนีในทฤษฎี SELECT DISTINCT OBJECT_NAME(s.[object_id]) AS ObjectName , p.rows TableRows , i.name AS [INDEX NAME] , (user_seeks + user_scans + user_lookups) AS TotalReads , user_updates UserUpdates FROM sys.dm_db_index_usage_stats s INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] AND i.index_id = …

11 sql-server  index  index-tuning  best-practices 

ฉันมีปัญหา I / O กับตารางขนาดใหญ่ สถิติทั่วไป ตารางมีลักษณะสำคัญดังต่อไปนี้: สภาพแวดล้อม: ฐานข้อมูล Azure SQL (ระดับชั้นเป็น P4 พรีเมียม (500 DTU)) แถว: 2,135,044,521 พาร์ติชันที่ใช้ 1,275 ดัชนีคลัสเตอร์และพาร์ติชัน แบบ นี่คือการใช้ตาราง: CREATE TABLE [data].[DemoUnitData]( [UnitID] [bigint] NOT NULL, [Timestamp] [datetime] NOT NULL, [Value1] [decimal](18, 2) NULL, [Value2] [decimal](18, 2) NULL, [Value3] [decimal](18, 2) NULL, CONSTRAINT [PK_DemoUnitData] PRIMARY KEY …

10 sql-server  query-performance  index-tuning  azure-sql-database 

ฉันอ่านหนังสือเล่มนี้ซึ่งบอกว่า ฐานข้อมูลสันนิษฐานว่า Indexed_Col IS NOT NULL ครอบคลุมช่วงที่มีขนาดใหญ่เกินไปที่จะเป็นประโยชน์ดังนั้นฐานข้อมูลจะไม่ขับไปยังดัชนีจากเงื่อนไขนี้ ฉันจำได้ว่าหนังสือเล่มนี้มีความเก่าแก่กว่า 10 ปี แต่ได้รับการพิสูจน์แล้วค่อนข้างมีประโยชน์ - การใช้คำแนะนำที่รวบรวมได้จากหน้าเว็บของตนฉันได้เร่งแบบสอบถามขึ้นโดยปัจจัยที่สิบ นอกจากนี้ในการทำงานEXPLAIN ANALYZEในSELECTแบบสอบถามที่ฉันได้พบว่าไม่มีการจัดทำดัชนีของฉันจะถูกนำมาใช้แม้ในขณะที่สิทธิทั้งหมดที่พวกเขาควรจะเป็น ดังนั้นคำถามของฉันคือ: สมมติว่ามีตารางที่มีคอลัมน์ซึ่งคำจำกัดความของคอลัมน์รวมถึง "NOT NULL" และดัชนีที่มีอยู่ซึ่งครอบคลุมคอลัมน์นี้ดัชนีนี้จะถูกใช้ในแบบสอบถามของตารางนั้นซึ่งคอลัมน์เป็นส่วนหนึ่งของแบบสอบถามหรือไม่ ชอบ: CREATE TABLE my_table( a varchar NOT NULL ); CREATE INDEX ix_my_table ON my_table(a); SELECT a from my_table;

10 postgresql  index  index-tuning  postgresql-9.1