คำถามติดแท็ก sql-server

Microsoft SQL Server ทุกรุ่น (ไม่ใช่ MySQL) โปรดเพิ่มแท็กเฉพาะเวอร์ชันเช่น sql-server-2016 เนื่องจากมักเกี่ยวข้องกับคำถาม

2
เหตุใดตัวแปรตารางบังคับให้สแกนดัชนีในขณะที่ตาราง temp ใช้การค้นหาและคั่นหน้าการค้นหา
ฉันพยายามที่จะเข้าใจว่าทำไมการใช้ตัวแปรตารางทำให้เครื่องมือเพิ่มประสิทธิภาพไม่สามารถใช้การค้นหาดัชนีจากนั้นทำบุ๊กมาร์กการค้นหากับการสแกนดัชนี การเติมตาราง: CREATE TABLE dbo.Test ( RowKey INT NOT NULL PRIMARY KEY, SecondColumn CHAR(1) NOT NULL DEFAULT 'x', ForeignKey INT NOT NULL ) INSERT dbo.Test ( RowKey, ForeignKey ) SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY (SELECT 0)), ABS(CHECKSUM(NEWID()) % 10) FROM sys.all_objects s1 CROSS JOIN sys.all_objects s2 CREATE INDEX …

1
TVF ที่มีหลายงบและประสิทธิภาพแบบอินไลน์ TVF
การเปรียบเทียบคำตอบบางส่วนกับคำถาม Palindrome (เฉพาะผู้ใช้ 10k + เท่านั้นเนื่องจากฉันได้ลบคำตอบแล้ว) ฉันจึงได้ผลลัพธ์ที่สับสน ฉันเสนอTVFซึ่งมีหลายสคีมาซึ่งฉันคิดว่าน่าจะเร็วกว่าการใช้งานฟังก์ชั่นมาตรฐานซึ่งเป็น ฉันยังอยู่ภายใต้ความประทับใจที่ TVF หลายงบจะ "อินไลน์" แม้ว่าฉันจะผิดในการนับที่คุณจะเห็นด้านล่าง คำถามนี้เกี่ยวกับความแตกต่างด้านประสิทธิภาพของ TVF ทั้งสองรูปแบบ ก่อนอื่นคุณจะต้องเห็นรหัส นี่คือ TVF หลายงบ: IF OBJECT_ID('dbo.IsPalindrome') IS NOT NULL DROP FUNCTION dbo.IsPalindrome; GO CREATE FUNCTION dbo.IsPalindrome ( @Word NVARCHAR(500) ) RETURNS @t TABLE ( IsPalindrome BIT NOT NULL ) WITH SCHEMABINDING AS BEGIN DECLARE …

4
สำหรับ XML ไม่สามารถทำให้ข้อมูลเป็นอนุกรมเนื่องจากมีอักขระ (0x0000)
ฉันมีคำถามใหญ่ (ถ้าจำเป็นฉันจะโพสต์ไว้ที่นี่) และฉันได้รับข้อผิดพลาดนี้: ข่าวสารเกี่ยวกับ 6841, ระดับ 16, สถานะ 1, บรรทัดที่ 1 สำหรับ XML ไม่สามารถทำให้เป็นอนุกรมข้อมูลสำหรับโหนด 'NoName' เนื่องจากมีอักขระ (0x0000) ซึ่งไม่ได้รับอนุญาตใน XML ในการดึงข้อมูลนี้โดยใช้ FOR XML ให้แปลงเป็นประเภทข้อมูลไบนารี, varbinary หรือรูปภาพและใช้คำสั่ง BINARY BASE64 ส่วนเดียวที่ฉันใช้FOR XMLอยู่ที่นี่: WHERE (CodFuncionario = Results.CodFuncionario) FOR XML PATH(''), TYPE).value('(./text())[1]', 'VARCHAR(MAX)'), 1, 2, '') AS [Experiencia] แต่อะไรนะnode noname? และฉันจะมองหาค่านี้ได้อย่างไร:(0x0000) นี่เป็นหนึ่งในแบบสอบถามย่อย (ส่วนเดียวที่ฉันมีสำหรับ XML): SELECT …

12
ใช้อักษรตัวแรกของแต่ละคำของแต่ละประโยคใน SQL Server
ฉันต้องการใช้อักษรตัวแรกของแต่ละคำของแต่ละประโยคในคอลัมน์ SQL ตัวอย่างเช่นถ้าประโยคคือ: 'ฉันชอบภาพยนตร์' แล้วฉันต้องการผลลัพธ์: 'ฉันชอบหนัง' ค้นหา: declare @a varchar(15) set @a = 'qWeRtY kEyBoArD' select @a as [Normal text], upper(@a) as [Uppercase text], lower(@a) as [Lowercase text], upper(left(@a,1)) + lower(substring(@a,2,len(@a))) as [Capitalize first letter only] ที่นี่ฉันเขียนอักษรตัวแรกตัวบนล่างและพิมพ์ใหญ่ในคอลัมน์ของฉันเท่านั้น (ที่นี่ฉันใส่คำแบบสุ่ม) นี่คือผลลัพธ์ของฉัน: มีความเป็นไปได้ที่จะทำเช่นนั้น? ความเป็นไปได้ใด ๆ ที่จะได้ผลลัพธ์โดยไม่ต้องใช้ฟังก์ชั่นที่ผู้ใช้กำหนด? ฉันต้องการผลลัพธ์ Qwerty Keyboard

2
วิธีวัดหรือค้นหาค่าใช้จ่ายในการสร้างแผนแบบสอบถาม
ฉันมีกรณีทั่วไปที่การดมพารามิเตอร์ทำให้แผนการดำเนินการ "ไม่ดี" ลงจอดในแคชแผนทำให้การดำเนินการที่ตามมาของโพรซีเดอร์ที่เก็บไว้ของฉันช้ามาก ฉันสามารถ "แก้" ปัญหานี้กับตัวแปรท้องถิ่นและOPTIMIZE FOR ... UNKNOWN OPTION(RECOMPILE)อย่างไรก็ตามฉันสามารถดำน้ำในแบบสอบถามและพยายามปรับให้เหมาะสม ฉันพยายามที่จะตรวจสอบว่าฉันควร : กำหนดเวลาที่ จำกัด ในการแก้ไขปัญหาที่ฉันต้องการทราบค่าใช้จ่ายของการไม่ทำมัน ตามที่เห็นถ้าฉันเพิ่งติดกับOPTION(RECOMPILE)ผลกระทบสุทธิคือแผนแบบสอบถามจะถูกสร้างขึ้นใหม่ทุกครั้งที่มีการเรียกใช้แบบสอบถาม ดังนั้นฉันคิดว่าฉันต้องรู้: จะทราบได้อย่างไรว่าต้นทุนการสร้างแผนแบบสอบถามเป็นอย่างไร เพื่อตอบคำถามของฉันฉันได้ Googled (เช่นกับการค้นหานี้ ) และฉันได้อ่านเอกสารของคอลัมน์สำหรับ dm_exec_query_statsDMVแล้ว ฉันได้ตรวจสอบหน้าต่างผลลัพธ์ใน SSMS สำหรับ "Actual Query Plan" เพื่อค้นหาข้อมูลนี้ สุดท้ายผมได้DBA.SE สืบค้น ไม่มีคำตอบใดที่นำไปสู่ มีใครบอกฉันได้บ้าง เป็นไปได้หรือไม่ที่จะค้นหาหรือวัดเวลาที่จำเป็นสำหรับการสร้างแผน

3
ดัชนีคอลัมน์แบบคลัสเตอร์และคีย์ต่างประเทศ
ฉันกำลังปรับแต่งคลังข้อมูลโดยใช้ดัชนี ฉันค่อนข้างใหม่กับ SQL Server 2014 Microsoft อธิบายต่อไปนี้: "เราดูดัชนี columnstore ของคลัสเตอร์เป็นมาตรฐานสำหรับการจัดเก็บตารางข้อมูลคลังข้อมูลขนาดใหญ่และคาดว่าจะใช้ในสถานการณ์จำลองคลังข้อมูลส่วนใหญ่เนื่องจากดัชนี columnstore ของคลัสเตอร์สามารถอัปเดตได้เวิร์กโหลดของคุณสามารถทำการแทรกจำนวนมาก และลบการทำงาน " http://msdn.microsoft.com/en-us/library/gg492088.aspx อย่างไรก็ตามหากคุณอ่านเพิ่มเติมในเอกสารคุณจะพบภายใต้ข้อ จำกัด และข้อ จำกัด : "ไม่สามารถมีข้อ จำกัด ที่ไม่ซ้ำกันข้อ จำกัด ของคีย์หลักหรือข้อ จำกัด ของ Foreign Key" ทำให้ฉันงงมาก! เป็นวิธีปฏิบัติที่ดี (ไม่บังคับ) ให้มีคีย์ต่างประเทศในคลังข้อมูลด้วยเหตุผลหลายประการ (ความสมบูรณ์ของข้อมูลความสัมพันธ์ที่มองเห็นได้สำหรับเลเยอร์ความหมาย ... ) ดังนั้นไมโครซอฟท์จึงสนับสนุนการจัดทำดัชนีคอลัมน์แบบจัดกลุ่มสำหรับสถานการณ์คลังข้อมูล แต่มันไม่สามารถจัดการกับความสัมพันธ์ที่สำคัญกับต่างประเทศได้! ฉันถูกต้องหรือไม่ วิธีอื่นใดที่คุณจะแนะนำ ในอดีตที่ผ่านมาฉันใช้ดัชนี columnstore ที่ไม่ใช่คลัสเตอร์ในสถานการณ์ data warehouse โดยมีการปล่อยและสร้างใหม่สำหรับการโหลดข้อมูล อย่างไรก็ตาม SQL Server 2014 …

1
“ ไม่สามารถสร้างแถวที่มีขนาด 8074 ซึ่งมากกว่าขนาดแถวสูงสุดที่อนุญาตได้ที่ 8060” ในขณะที่เปลี่ยนตาราง
ฉันกำลังพยายามเปลี่ยนคอลัมน์ในตาราง ตารางที่มีอยู่เป็นดังนี้: CREATE TABLE [dbo].[table]( [id1] [int] NOT NULL, [id2] [int] NOT NULL, [id3] [int] NOT NULL, [name] [nvarchar](255) NOT NULL, [id4] [int] NOT NULL, [xmlData] [xml](CONTENT [dbo].[xml_schema]) NULL, [booleanData1] [bit] NOT NULL, [notes] [varchar](4096) NULL, [id5] [int] NULL, [booleanData2] [bit] NULL, [id6] [int] NULL, CONSTRAINT [PK_table] PRIMARY KEY CLUSTERED …

2
ประสิทธิภาพการเลื่อนหน้าด้วยการเรียงลำดับที่กำหนดเองได้หลายล้านแถว
ในแอปพลิเคชันของเราเรามีตารางที่ผู้ใช้สามารถเลื่อนดูระเบียนจำนวนมาก (10-20 ล้าน) กริดรองรับการเรียงลำดับจากน้อยไปมากและจากมากไปน้อยในคอลัมน์จำนวนมาก (20+) ค่าจำนวนมากยังไม่ซ้ำกันดังนั้นแอปพลิเคชันจึงเรียงลำดับตาม id เป็นตัวแบ่งไทม์เบรกเพื่อให้แน่ใจว่าแถวปรากฏบนหน้าเดียวกันเสมอ ตัวอย่างเช่นหากผู้ใช้ต้องการเรียงลำดับตามขนาดวิดเจ็ต (เริ่มต้นที่ใหญ่ที่สุด) แอปพลิเคชันจะสร้างคิวรีที่มีลักษณะดังนี้: SELECT TOP 30 * -- (Pretend that there is a list of columns here) FROM Test -- WHERE widgetSize > 100 ORDER BY widgetSize DESC, id ASC เคียวรีนี้ใช้เวลา ~ 15s ในการรัน (ด้วยข้อมูลที่แคช) ค่าใช้จ่ายส่วนใหญ่ดูเหมือนจะเรียงลำดับแถว ~ 1.3m โดย widgetSize ในความพยายามที่จะปรับแต่งแบบสอบถามนี้ฉันค้นพบว่าถ้าฉันเพิ่มในWHEREประโยคที่ จำกัด …

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

1
การใช้ DISTINCT เป็นคำใบ้ในแบบสอบถามย่อยมีประโยชน์หรือไม่
การเพิ่มDISTINCTในตัวอย่างต่อไปนี้มีผลกระทบต่อเวลาทำงานของแบบสอบถามหรือไม่ ควรใช้เป็นคำใบ้ในบางครั้งหรือไม่? SELECT * FROM A WHERE A.SomeColumn IN (SELECT DISTINCT B.SomeColumn FROM B)

6
อย่าใช้ธุรกรรมสำหรับกระบวนงานที่เก็บไว้
ฉันมีขั้นตอนการจัดเก็บที่รันคำสั่งไม่กี่คำ ฉันไม่ต้องการให้ห่อคำสั่งเหล่านี้ในธุรกรรมของกระบวนงานที่เก็บไว้ หากคำสั่งที่ 4 ล้มเหลวฉันต้องการให้อันดับที่ 1, ที่ 2 และที่ 3 อยู่และไม่ย้อนกลับ เป็นไปได้ไหมที่จะเขียนโพรซีเดอร์ที่เก็บไว้ในลักษณะที่มันไม่ได้ดำเนินการทั้งหมดในการทำธุรกรรมครั้งใหญ่?

3
แยกการสืบค้น SQL ที่มีการรวมเป็นจำนวนน้อย
เราต้องทำการรายงานบางอย่างทุกคืนใน SQL Server 2008 R2 ของเรา การคำนวณรายงานใช้เวลาหลายชั่วโมง เพื่อที่จะย่นเวลาเราจะคำนวณตารางล่วงหน้า ตารางนี้สร้างขึ้นจากการเข้าร่วม 12 ตารางที่มีขนาดค่อนข้างใหญ่ (หลายสิบล้านแถว) การคำนวณตารางรวมนี้ใช้เวลาไม่กี่วันที่ผ่านมา cca 4 ชั่วโมง DBA ของเราดีกว่าแบ่งการรวมครั้งใหญ่นี้ออกเป็น 3 การรวมที่เล็กกว่า (แต่ละการรวม 4 ตาราง) ผลลัพธ์ชั่วคราวจะถูกบันทึกลงในตารางชั่วคราวทุกครั้งที่ใช้ในการเข้าร่วมครั้งต่อไป ผลลัพธ์ของการปรับปรุง DBA คือตารางการรวมจะถูกคำนวณใน 15 นาที ฉันสงสัยว่าเป็นไปได้อย่างไร DBA บอกฉันว่ามันเป็นเพราะจำนวนข้อมูลที่เซิร์ฟเวอร์ต้องดำเนินการมีขนาดเล็กลง กล่าวอีกนัยหนึ่งว่าในการเข้าร่วมต้นฉบับใหญ่เซิร์ฟเวอร์ต้องทำงานกับข้อมูลมากกว่าการรวมตัวเล็กลง อย่างไรก็ตามฉันจะสันนิษฐานว่าเครื่องมือเพิ่มประสิทธิภาพจะดูแลการทำอย่างมีประสิทธิภาพด้วยการเข้าร่วมครั้งใหญ่โดยแยกการรวมเข้าด้วยกันและส่งเฉพาะจำนวนคอลัมน์ที่จำเป็นสำหรับการเข้าร่วมครั้งต่อไป อีกสิ่งที่เขาทำคือเขาสร้างดัชนีในหนึ่งในตารางชั่วคราว อย่างไรก็ตามอีกครั้งฉันคิดว่าเครื่องมือเพิ่มประสิทธิภาพจะสร้างตารางแฮชที่เหมาะสมหากจำเป็น ฉันพูดคุยเกี่ยวกับเรื่องนี้กับ DBA ของเรา แต่เขาเองก็ไม่แน่ใจเกี่ยวกับสิ่งที่ทำให้เวลาในการปรับปรุงดีขึ้น เขาเพิ่งพูดถึงว่าเขาจะไม่ตำหนิเซิร์ฟเวอร์เพราะมันมีจำนวนมหาศาลในการคำนวณข้อมูลขนาดใหญ่และเป็นไปได้ว่าเครื่องมือเพิ่มประสิทธิภาพมีเวลายากที่จะคาดการณ์แผนการดำเนินการที่ดีที่สุด ... ฉันเข้าใจสิ่งนี้ แต่ฉันต้องการคำตอบที่ชัดเจนยิ่งขึ้นว่าทำไม ดังนั้นคำถามคือ: สิ่งที่อาจทำให้เกิดการปรับปรุงครั้งใหญ่? มันเป็นขั้นตอนมาตรฐานในการแยกการรวมขนาดใหญ่ออกเป็นเล็กหรือไม่? ปริมาณของข้อมูลที่เซิร์ฟเวอร์มีการประมวลผลที่เล็กกว่าจริง ๆ ในกรณีที่มีการรวมขนาดเล็กหลายครั้งหรือไม่? …

7
จัดตารางเวลารายวันเป็น [วันที่เริ่ม; วันที่สิ้นสุด] ช่วงเวลาพร้อมรายการวันในสัปดาห์
ฉันต้องการแปลงข้อมูลระหว่างสองระบบ ระบบแรกจัดเก็บตารางเวลาเป็นรายการธรรมดาของวันที่ แต่ละวันที่รวมอยู่ในกำหนดการคือหนึ่งแถว อาจมีช่องว่างต่าง ๆ ในลำดับของวันที่ (วันหยุดสุดสัปดาห์วันหยุดราชการและหยุดอีกต่อไปบางวันของสัปดาห์อาจไม่รวมอยู่ในตาราง) ไม่มีช่องว่างเลยแม้แต่วันหยุดสุดสัปดาห์ก็สามารถรวม กำหนดการอาจนานถึง 2 ปี โดยปกติจะใช้เวลาไม่กี่สัปดาห์ นี่คือตัวอย่างง่ายๆของตารางที่ครอบคลุมสองสัปดาห์ยกเว้นวันหยุดสุดสัปดาห์ (มีตัวอย่างที่ซับซ้อนมากขึ้นในสคริปต์ด้านล่าง): +----+------------+------------+---------+--------+ | ID | ContractID | dt | dowChar | dowInt | +----+------------+------------+---------+--------+ | 10 | 1 | 2016-05-02 | Mon | 2 | | 11 | 1 | 2016-05-03 | Tue | 3 | | …

1
การสำรองข้อมูล shadow volume ของไฟล์ mdf และ ldf ปลอดภัยหรือไม่?
เรากำลังมองหาการแทนที่การสำรองข้อมูลเซิร์ฟเวอร์ SQL แบบดั้งเดิมด้วยการสำรองข้อมูลตาม VSS ของไฟล์ mdf และ ldf ในฐานะที่เป็นคนดีบีฉันค่อนข้างกระวนกระวายใจเกี่ยวกับเรื่องนี้ แต่ฉันก็ยังหาหลักฐานไม่ได้ว่าสิ่งนี้จะไม่ทำงานใช่ไหม ทุกคนสามารถแนะนำการทดลองใช้ที่ฉันสามารถตั้งค่าที่จะแสดงให้เห็นว่าเราสามารถทำธุรกรรมด้วยกลยุทธ์นี้ได้ที่ไหน [การดึงสายไฟออกระหว่างการทำธุรกรรมที่ใช้เวลานานเป็นเรื่องปกติ] ระบบที่เรากำลังดูสร้างสแนปชอตเริ่มต้นของไฟล์ mdf และ ldf จากนั้นคัดลอกข้ามการเปลี่ยนแปลง ฉันไม่สามารถจินตนาการถึงสถานการณ์ที่อาจทำให้เราล้มเหลว หวังว่าคุณสามารถช่วยฉันโน้มน้าวเจ้านายของฉันได้ว่าเราต้องสำรองข้อมูลแบบเดิมเอาไว้!
18 sql-server 

2
เป็นไปได้ไหมที่จะเพิ่มประสิทธิภาพให้มากขึ้นหรือทุกเวลาที่ต้องการ?
เนื่องจากเครื่องมือเพิ่มประสิทธิภาพไม่สามารถใช้เวลาทั้งหมดได้ตามต้องการ (ต้องลดเวลาการดำเนินการให้สั้นลงและไม่สนับสนุน) เพื่อสำรวจแผนปฏิบัติการที่เป็นไปได้ทั้งหมดซึ่งบางครั้งอาจถูกตัดออก ฉันสงสัยว่าสิ่งนี้สามารถถูกแทนที่ได้หรือไม่เพื่อที่คุณจะสามารถให้เครื่องมือเพิ่มประสิทธิภาพตลอดเวลาที่ต้องการ (หรือจำนวนมิลลิวินาทีที่แน่นอน) ฉันไม่จำเป็นต้องใช้ (atm) นี้ แต่ฉันสามารถจินตนาการถึงสถานการณ์ที่มีการดำเนินการค้นหาที่ซับซ้อนในลูปและคุณต้องการแผนการที่เหมาะสมและแคชก่อนมือ แน่นอนว่าคุณมีการวนรอบที่แน่นหนาคุณควรเขียนแบบสอบถามใหม่เพื่อให้มันหายไป แต่ทนกับฉัน นี่เป็นคำถามที่เกิดจากความอยากรู้อยากเห็นมากขึ้นและเพื่อดูว่าบางครั้งมีความแตกต่างระหว่างการปรับให้เหมาะสมแบบลัดและแบบเต็ม ปรากฎว่าคุณสามารถเพิ่มประสิทธิภาพให้กับเวลามากขึ้นด้วยการตั้งค่าสถานะการสืบค้นกลับ 2301 ไม่ใช่สิ่งที่ฉันขอ แต่มันใกล้เข้ามา ข้อมูลที่ดีที่สุดที่ฉันพบในที่นี้คือในQuery Processor Modelling Extensions ใน SQL Server 2005 SP1โดย Ian Jose ใช้แฟล็กการติดตามนี้ด้วยความระมัดระวัง! แต่มันจะมีประโยชน์เมื่อคิดแผนที่ดีกว่า ดูสิ่งนี้ด้วย: บทความที่ติดแท็ก"ระดับการเพิ่มประสิทธิภาพ"โดย Grant Fritchey ก่อนที่คุณจะอัพเกรดเป็น SQL Server 2008 ...โดย Brent Ozar ตัวเลือกการปรับแต่งสำหรับ SQL Server เมื่อทำงานในปริมาณงานที่มีประสิทธิภาพสูงโดยฝ่ายสนับสนุนของ Microsoft ฉันกำลังคิดเกี่ยวกับข้อความค้นหาที่มีการเข้าร่วมจำนวนมากซึ่งพื้นที่โซลูชันสำหรับการเข้าร่วมคำสั่งซื้อจะเพิ่มขึ้นแบบทวีคูณ ฮิวริสติกที่ SQL Server ใช้นั้นค่อนข้างดี …

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