คำถามติดแท็ก query-performance

ถามคำถามนี้โดยเฉพาะสำหรับ Postgres เนื่องจากมี supoort ที่ดีสำหรับดัชนี R-tree / spatial เรามีตารางต่อไปนี้พร้อมโครงสร้างแบบต้นไม้ (ชุดแบบซ้อน) ของคำและความถี่: lexikon ------- _id integer PRIMARY KEY word text frequency integer lset integer UNIQUE KEY rset integer UNIQUE KEY และแบบสอบถาม: SELECT word FROM lexikon WHERE lset BETWEEN @Low AND @High ORDER BY frequency DESC LIMIT @N ฉันคิดว่าดัชนีการครอบคลุม(lset, frequency, word)จะมีประโยชน์ แต่ฉันรู้สึกว่ามันอาจทำงานได้ไม่ดีหากมีlsetค่ามากเกินไปใน(@High, …

29 postgresql  database-design  index  query-performance 

เรามีคลังข้อมูลที่มีจำนวนเรกคอร์ดที่ค่อนข้างใหญ่ (10-20 ล้านแถว) และมักเรียกใช้คิวรีที่นับเร็กคอร์ดระหว่างวันที่แน่นอนหรือนับจำนวนเรกคอร์ดด้วยค่าสถานะที่แน่นอนเช่น SELECT f.IsFoo, COUNT(*) AS WidgetCount FROM Widgets AS w JOIN Flags AS f ON f.FlagId = w.FlagId WHERE w.Date >= @startDate GROUP BY f.IsFoo ประสิทธิภาพไม่น่ากลัว แต่อาจค่อนข้างเชื่องช้า (อาจใช้เวลา 10 วินาทีในแคชเย็น) เมื่อเร็ว ๆ นี้ฉันค้นพบว่าฉันสามารถใช้GROUP BYในมุมมองที่จัดทำดัชนีและลองใช้บางสิ่งที่คล้ายกับต่อไปนี้ CREATE VIEW TestView WITH SCHEMABINDING AS SELECT Date, FlagId, COUNT_BIG(*) AS WidgetCount FROM …

28 sql-server  index  query-performance  materialized-view 

ฉันกำลังอัปเดตโดยที่ฉันต้องการความเท่าเทียมกันแน่นอนในtstzrangeตัวแปร แถว ~ 1M มีการแก้ไขและแบบสอบถามใช้เวลาประมาณ 13 นาที ผลลัพธ์ของEXPLAIN ANALYZEสามารถเห็นได้ที่นี่และผลลัพธ์ที่แท้จริงแตกต่างอย่างมากจากที่ประเมินโดยผู้วางแผนแบบสอบถาม ปัญหาคือการสแกนดัชนีt_rangeคาดว่าจะส่งคืนแถวเดียว สิ่งนี้น่าจะเกี่ยวข้องกับความจริงที่ว่าสถิติของประเภทช่วงนั้นถูกจัดเก็บแตกต่างจากประเภทอื่น ๆ มองไปที่pg_statsมุมมองสำหรับคอลัมน์ที่n_distinctเป็น -1 และสาขาอื่น ๆ (เช่นmost_common_vals, most_common_freqs) เป็นที่ว่างเปล่า อย่างไรก็ตามจะต้องมีสถิติเก็บไว้ในt_rangeบางแห่ง การอัปเดตที่คล้ายกันอย่างยิ่งซึ่งฉันใช้ 'ภายใน' บน t_range แทนที่จะใช้ความเท่าเทียมกันที่แน่นอนใช้เวลาประมาณ 4 นาทีในการดำเนินการและใช้แผนคิวรีที่แตกต่างกันอย่างมาก (ดูที่นี่ ) แผนคิวรีที่สองนั้นสมเหตุสมผลสำหรับฉันเพราะทุกแถวในตาราง temp และส่วนสำคัญของตารางประวัติจะถูกนำมาใช้ t_rangeที่สำคัญกว่าการวางแผนแบบสอบถามคาดการณ์ตัวเลขให้ถูกต้องประมาณแถวสำหรับกรอง การกระจายตัวของt_rangeมันค่อนข้างผิดปกติ ฉันใช้ตารางนี้เพื่อเก็บสถานะทางประวัติศาสตร์ของตารางอื่นและการเปลี่ยนแปลงของตารางอื่น ๆ เกิดขึ้นพร้อมกันในการทิ้งขนาดใหญ่ดังนั้นจึงมีค่าที่แตกต่างกันไม่มากt_rangeนัก นี่คือการนับที่สอดคล้องกับค่าที่ไม่ซ้ำกันของt_range: t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") …

28 postgresql  query-performance  postgresql-9.3  postgresql-performance  range-types 

มันสร้างความแตกต่างหรือไม่ถ้าคุณกรองมุมมองภายในหรือภายนอกมุมมอง ตัวอย่างเช่นมีข้อแตกต่างระหว่างสองข้อความค้นหานี้หรือไม่ SELECT Id FROM MyTable WHERE SomeColumn = 1 หรือ SELECT Id FROM MyView WHERE SomeColumn = 1 และMyViewถูกกำหนดให้เป็น SELECT Id, SomeColumn FROM MyTable และเป็นคำตอบที่แตกต่างกันหรือไม่หากตารางต้นฉบับตั้งอยู่บนเซิร์ฟเวอร์ที่เชื่อมโยง ฉันถามเพราะฉันต้องค้นหาตารางขนาดใหญ่ (44mil แถว) สองครั้งจากเซิร์ฟเวอร์ที่เชื่อมโยงและรับผลรวม ฉันต้องการทราบว่าฉันควรสร้างสองมุมมองเพื่อเข้าถึงข้อมูลหรือไม่สำหรับแต่ละแบบสอบถามหรือถ้าฉันสามารถออกไปได้ด้วยมุมมองเดียวและWHEREประโยค

28 sql-server  sql-server-2005  view  query-performance 

พิจารณาแผนแบบสอบถามต่อไปนี้ใน SQL Server 2014: ในแผนแบบสอบถามการเข้าร่วมด้วยตนเองar.fId = ar.fIdจะให้ผลประมาณ 1 แถว อย่างไรก็ตามนี่เป็นค่าประมาณที่ไม่สอดคล้องกันเชิงตรรกะ: arมี20,608แถวและมีค่าที่แตกต่างกันเพียงหนึ่งค่าfId(สะท้อนให้เห็นอย่างถูกต้องในสถิติ) ดังนั้นการเข้าร่วมนี้จะสร้างผลิตภัณฑ์ไขว้เต็มของแถว ( ~424MMแถว) ทำให้คิวรีทำงานเป็นเวลาหลายชั่วโมง ฉันมีเวลายากที่จะเข้าใจว่าทำไม SQL Server ถึงได้มีการประมาณการที่สามารถพิสูจน์ได้อย่างง่ายดายว่าไม่สอดคล้องกับสถิติ ความคิดใด ๆ การตรวจสอบเบื้องต้นและรายละเอียดเพิ่มเติม จากคำตอบของ Paul ที่นี่ดูเหมือนว่าทั้งฮิวริสติก SQL 2012 และ SQL 2014 สำหรับการประเมิน cardinality ที่เข้าร่วมควรจัดการสถานการณ์ที่ฮิสโทแกรมที่เหมือนกันทั้งสองต้องเปรียบเทียบได้ง่าย ฉันเริ่มต้นด้วยผลลัพธ์จากการตั้งค่าสถานะการสืบค้นกลับ 2363 แต่ไม่สามารถเข้าใจได้อย่างง่ายดาย ตัวอย่างต่อไปนี้หมายความว่า SQL Server เปรียบเทียบฮิสโตแกรมสำหรับfIdและbIdเพื่อประเมินการเลือกของการเข้าร่วมที่ใช้เท่านั้นfIdหรือไม่ ถ้าเป็นเช่นนั้นแน่นอนว่าจะไม่ถูกต้อง หรือฉันกำลังอ่านเอาต์พุตแฟล็กการติดตามผิด? Plan for computation: CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: …

27 sql-server  query-performance  sql-server-2014  execution-plan  cardinality-estimates 

ฉันมีฐานข้อมูลที่ฉันโหลดไฟล์ลงในตารางการแสดงละครจากตารางการแสดงนี้ฉันมี 1-2 ร่วมเพื่อแก้ไขคีย์ต่างประเทศแล้วใส่แถวนี้ลงในตารางสุดท้าย (ซึ่งมีหนึ่งพาร์ติชันต่อเดือน) ฉันมีข้อมูลประมาณ 3.4 พันล้านแถวสำหรับสามเดือน วิธีที่เร็วที่สุดในการดึงแถวเหล่านี้จากการจัดเตรียมลงในตารางสุดท้ายคืออะไร SSIS Data Flow Task (ที่ใช้มุมมองเป็นแหล่งที่มาและมีการโหลดที่ใช้งานอย่างรวดเร็ว) หรือคำสั่งแทรกลงใน SELECT ... ฉันลอง Data Flow Task และสามารถรับประมาณ 1 พันล้านแถวในเวลาประมาณ 5 ชั่วโมง (8 cores / 192 GB RAM บนเซิร์ฟเวอร์) ซึ่งรู้สึกช้ามากสำหรับฉัน

27 sql-server  sql-server-2012  query-performance  insert 

ฉันรู้ว่าขั้นตอนการจัดเก็บมีประสิทธิภาพมากขึ้นผ่านเส้นทางการดำเนินการ (กว่า inline sql ในแอปพลิเคชัน) อย่างไรก็ตามเมื่อกดฉันไม่ได้รู้เรื่องทำไม ฉันต้องการทราบเหตุผลทางเทคนิคสำหรับเรื่องนี้ (ในแบบที่ฉันสามารถอธิบายให้ใครบางคนในภายหลัง) ใครสามารถช่วยฉันสร้างคำตอบที่ดีได้บ้าง

27 sql-server  stored-procedures  query-performance 

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

26 postgresql  index  query-performance  index-tuning  postgresql-performance 

ฉันมีคำถามที่น่าสนใจเกี่ยวกับ SARGability คืออะไร ในกรณีนี้มันเกี่ยวกับการใช้เพรดิเคตกับความแตกต่างระหว่างสองคอลัมน์วันที่ นี่คือการตั้งค่า: USE [tempdb] SET NOCOUNT ON IF OBJECT_ID('tempdb..#sargme') IS NOT NULL BEGIN DROP TABLE #sargme END SELECT TOP 1000 IDENTITY (BIGINT, 1,1) AS ID, CAST(DATEADD(DAY, [m].[severity] * -1, GETDATE()) AS DATE) AS [DateCol1], CAST(DATEADD(DAY, [m].[severity], GETDATE()) AS DATE) AS [DateCol2] INTO #sargme FROM sys.[messages] AS [m] …

24 sql-server  index  query-performance 

ฉันได้อ่านบทความเหล่านี้ใน PCMag โดยItzik Ben-Gan : แสวงหาและคุณจะสแกนส่วนที่ 1: เมื่อเครื่องมือเพิ่มประสิทธิภาพไม่ได้ปรับให้เหมาะสม แสวงหาและคุณจะสแกนส่วนที่สอง: คีย์จากน้อยไปมาก ขณะนี้ฉันมีปัญหา "Grouped Max" กับตารางที่แบ่งพาร์ติชันทั้งหมดของเรา เราใช้เคล็ดลับ Itzik Ben-Gan ที่ให้ไว้เพื่อรับ max (ID) แต่บางครั้งก็ไม่ได้ทำงาน: DECLARE @MaxIDPartitionTable BIGINT SELECT @MaxIDPartitionTable = ISNULL(MAX(IDPartitionedTable), 0) FROM ( SELECT * FROM ( SELECT partition_number PartitionNumber FROM sys.partitions WHERE object_id = OBJECT_ID('fct.MyTable') AND index_id = 1 ) T1 …

22 sql-server  query-performance  partitioning 

คำถามนี้เป็นคำถามที่เกี่ยวข้องกับคำถามเก่าของฉัน ข้อความค้นหาด้านล่างนี้ใช้เวลาดำเนินการ 10 ถึง 15 วินาที: SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE (Charindex('123456789',CAST([company].dbo.[customer].[Phone no] AS VARCHAR(MAX)))>0) ในบางบทความฉันเห็นว่าการใช้CASTและCHARINDEXจะไม่ได้รับประโยชน์จากการจัดทำดัชนี นอกจากนี้ยังมีบทความบางส่วนที่กล่าวว่าการใช้LIKE '%abc%'จะไม่ได้รับประโยชน์จากการทำดัชนีในขณะที่LIKE 'abc%': http://bytes.com/topic/sql-server/answers/81467-using-charindex-vs-like-where /programming/803783/sql-server-index-any-improvement- สำหรับ -like-query http://www.sqlservercentral.com/Forums/Topic186262-8-1.aspx#bm186568 ในกรณีของฉันฉันสามารถเขียนแบบสอบถามเป็น: SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE [company].dbo.[customer].[Phone no] LIKE '%123456789%' แบบสอบถามนี้ให้ผลลัพธ์เช่นเดียวกับรายการก่อนหน้า ผมได้สร้างดัชนี nonclustered Phone noสำหรับคอลัมน์ เมื่อผมดำเนินการค้นหานี้มันจะทำงานในเวลาเพียง1 วินาที นี่เป็นการเปลี่ยนแปลงครั้งใหญ่เมื่อเทียบกับ14 วินาทีก่อนหน้านี้ วิธีการที่ไม่LIKE '%123456789%'ได้รับประโยชน์จากการจัดทำดัชนี? เหตุใดบทความที่ระบุจึงไม่สามารถปรับปรุงประสิทธิภาพได้ ฉันพยายามเขียนแบบสอบถามใหม่เพื่อใช้CHARINDEXแต่ประสิทธิภาพยังคงช้า เหตุใดจึงไม่CHARINDEXได้ประโยชน์จากการจัดทำดัชนีตามที่ปรากฏในLIKEแบบสอบถาม …

22 sql-server-2008-r2  index  query-performance 

ฉันต้องการแบบสอบถามที่สามารถใช้ใน (หรือตาม) ฟังก์ชั่นและดึงการรวมกันของค่า n ทั้งหมด และฉันต้องการความยาวทั้งหมด k โดยที่ k = 1..n ตัวอย่างอินพุตเพิ่มเติมและผลลัพธ์ดังนั้นอินพุตมี 3 ค่าแทน 2 อย่างไรก็ตามจำนวนค่าอินพุตอาจแตกต่างจาก 1 ถึง n ตัวอย่าง: อินพุต: ตารางที่มีค่าในหนึ่งคอลัมน์ในหลายแถว Value (nvarchar(500)) ------ Ann John Mark เอาท์พุท # 1: ตารางที่มีค่าต่อกันในหนึ่งคอลัมน์ Ann John Mark Ann,John John,Mark Ann,Mark Ann,John,Mark

22 sql-server  query-performance 

สมมติว่าเรามีคำถามเช่นนี้: 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 …

21 sql-server  query-performance  execution-plan  database-internals 

ในตัวอย่างแบบสอบถามแผนต่อไปนี้ดูเหมือนว่าชัดเจนว่าการประมาณแถวสำหรับConcatenationผู้ประกอบการควรเป็น~4.3 billion rowsหรือผลรวมของแถวประมาณการสำหรับสองอินพุต อย่างไรก็ตามมีการประมาณค่าการ~238 million rowsผลิตซึ่งนำไปสู่การเพิ่มประสิทธิภาพย่อยSort/ Stream Aggregateกลยุทธ์ที่กระจายข้อมูลหลายร้อย GB ไปยัง tempdb การประมาณที่สอดคล้องกันอย่างมีเหตุผลในกรณีนี้จะทำให้เกิด a Hash Aggregateลบการรั่วไหลและเพิ่มประสิทธิภาพของแบบสอบถาม นี่เป็นข้อบกพร่องใน SQL Server 2014 หรือไม่ มีสถานการณ์ที่ถูกต้องหรือไม่ที่การประมาณการต่ำกว่าอินพุทอาจมีเหตุผลหรือไม่? วิธีแก้ไขปัญหาใดบ้างที่อาจมีอยู่ นี่คือแผนแบบสอบถามเต็มรูปแบบ (ไม่ระบุชื่อ) ฉันไม่สามารถดูแลระบบเข้าถึงเซิร์ฟเวอร์นี้เพื่อให้เอาต์พุตจากQUERYTRACEON 2363หรือแฟล็กการติดตามที่คล้ายกัน แต่อาจสามารถรับเอาต์พุตเหล่านี้จากผู้ดูแลระบบหากพวกเขาจะเป็นประโยชน์ ฐานข้อมูลอยู่ในระดับความเข้ากันได้ 120 ดังนั้นจึงใช้เครื่องมือประมาณการ Cardinality ใหม่ของ SQL Server 2014 สถิติจะถูกอัพเดตด้วยตนเองทุกครั้งที่มีการโหลดข้อมูล เมื่อพิจารณาจากปริมาณข้อมูลเรากำลังใช้อัตราการสุ่มตัวอย่างเริ่มต้น เป็นไปได้ว่าอัตราการสุ่มตัวอย่างที่สูงขึ้น (หรือFULLSCAN) อาจมีผลกระทบ

20 sql-server  query-performance  sql-server-2014  concat  cardinality-estimates 

ในขณะทำโปรไฟล์ฐานข้อมูลฉันพบว่ามีการอ้างอิงฟังก์ชั่นที่ไม่ได้กำหนดค่าบางอย่างที่เข้าถึง1,000-2500 ครั้งต่อนาทีสำหรับการเชื่อมต่อแต่ละครั้งในแอพพลิเคชั่นนี้ วิSELECTจากมุมมองทำให้แผนการดำเนินการต่อไปนี้: ดูเหมือนว่าแผนซับซ้อนสำหรับมุมมองที่มีน้อยกว่าหนึ่งพันแถวที่อาจเห็นการเปลี่ยนแปลงหนึ่งหรือสองแถวทุกสองสามเดือน แต่มันก็แย่ลงด้วยการปฏิบัติอื่น ๆ ดังต่อไปนี้: มุมมองแบบซ้อนไม่สามารถกำหนดค่าได้ดังนั้นเราจึงไม่สามารถจัดทำดัชนีได้ แต่ละมุมมองอ้างอิงหลายUDFs เพื่อสร้างสตริง UDF แต่ละอันประกอบด้วยUDFs ที่ซ้อนกันเพื่อรับรหัส ISO สำหรับภาษาที่แปลเป็นภาษาท้องถิ่น ผู้ชมในกองกำลังใช้เพิ่มเติมสร้างสตริงกลับมาจากUDFการเป็นJOINภาค มุมมองสแต็กแต่ละครั้งจะถือว่าเป็นตารางหมายความว่ามีINSERT/ UPDATE/ DELETEทริกเกอร์ในแต่ละเพื่อเขียนไปยังตารางพื้นฐาน ทริกเกอร์เหล่านี้ในมุมมองใช้CURSORSว่าEXECวิธีการจัดเก็บที่อ้างอิงมากกว่านี้สตริงสร้างUDFs ดูเหมือนว่าฉันจะเน่าเสีย แต่ฉันมีประสบการณ์กับ TSQL เพียงไม่กี่ปี มันจะดีขึ้นเช่นกัน! ดูเหมือนนักพัฒนาที่ตัดสินใจว่านี่เป็นความคิดที่ยอดเยี่ยมทำทั้งหมดนี้เพื่อให้สตริงสองสามร้อยรายการที่เก็บไว้สามารถมีการแปลตามสตริงที่ส่งคืนจากสตริงUDFนั้นเป็นแบบเฉพาะสคีมา นี่คือหนึ่งในมุมมองในสแต็ก แต่ทั้งหมดนั้นไม่ดีเท่ากัน: CREATE VIEW [UserWKStringI18N] AS SELECT b.WKType, b.WKIndex , CASE WHEN ISNULL(il.I18NID, N'') = N'' THEN id.I18NString ELSE il.I18nString END AS WKString ,CASE …

20 sql-server  sql-server-2008-r2  query-performance  view  functions