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

แบ่งตารางฐานข้อมูลออกเป็นหลายส่วนเพื่อประสิทธิภาพหรือความสามารถในการจัดการ

2
SQL Server 2008 - ดัชนีการแบ่งพาร์ติชันและคลัสเตอร์
ดังนั้นให้ฉันนำหน้าด้วยการบอกว่าฉันไม่สามารถควบคุมการออกแบบฐานข้อมูลของฉันได้ทั้งหมดดังนั้นแง่มุมมากมายของระบบปัจจุบันจึงไม่สามารถเปลี่ยนแปลงได้ตามวัตถุประสงค์ของสถานการณ์นี้ ความคิดเห็นเกี่ยวกับวิธีที่เราคิดใหม่แง่มุมของการออกแบบน่าจะถูกต้อง แต่ไม่ช่วยเหลือ :) ฉันมีตารางที่มีขนาดใหญ่มากกว้างประมาณ 150 ฟิลด์และแถวประมาณ 600 ม. ซึ่งขับเคลื่อนกระบวนการจำนวนมาก นี่คือสถานการณ์ในคลังข้อมูลดังนั้นเราจึงไม่มีการอัปเดต / แทรกใด ๆ นอกกระบวนการโหลดตามกำหนดเวลาดังนั้นจึงมีการจัดทำดัชนีอย่างหนัก มีการตัดสินใจที่จะลองแบ่งพาร์ติชันตารางนี้และฉันมีความกังวลเกี่ยวกับการทำดัชนีตารางที่แบ่งพาร์ติชัน ฉันไม่มีประสบการณ์ในการแบ่งพาร์ติชันดังนั้นอินพุตหรือลิงก์ใด ๆ ที่ชื่นชม ฉันไม่สามารถค้นหาสิ่งที่ฉันเป็นบน BOL หรือ msdn โดยเฉพาะได้ ขณะนี้เราจัดกลุ่มในฟิลด์ที่เราจะเรียกIncidentKeyซึ่งเป็นvarchar(50)และไม่ซ้ำกัน - เราสามารถมีได้ระหว่าง 1-100 รายการด้วยเหมือนกันIK(ไม่มีความคิดเห็นโปรด) เรามักจะได้รับข้อมูลใหม่ในIncidentKeyบันทึกเก่า ๆดังนั้นจึงไม่ต่อเนื่องกัน ฉันเข้าใจว่าฉันต้องรวมฟิลด์พาร์ติชันIncidentDateของฉันไว้ในคีย์ดัชนีคลัสเตอร์เพื่อให้พาร์ติชันทำงานได้อย่างถูกต้อง IncidentKey, IncidentDateฉันคิดว่ามันจะเป็น คำถามคือกลไกของดัชนีแบบคลัสเตอร์จะทำงานกับคีย์ 2 ส่วนในตารางที่แบ่งพาร์ติชันได้อย่างไรหากเร็กคอร์ดในพาร์ติชัน "ใหม่" ควรอยู่หน้าเร็กคอร์ดในพาร์ติชัน "เก่า" ในดัชนีคลัสเตอร์ ตัวอย่างเช่นฉันมี 5 บันทึก: IncidentKey Date ABC123 1/1/2010 ABC123 7/1/2010 …

1
คอลัมน์ sys.partition.rows มีความแม่นยำเพียงใด
มุมมองระบบsys.partitionsมีคอลัมน์ "แถว" ที่เป็นจำนวนแถวทั้งหมดในพาร์ติชันที่กำหนด สำหรับตารางที่ไม่ได้แบ่งพาร์ติชัน (หรือมีพาร์ติชันเดียวขึ้นอยู่กับวิธีที่คุณดู) คอลัมน์นี้ให้จำนวนแถวในตาราง SELECT COUNT(1) FROM TableNameฉันอยากรู้วิธีที่ถูกต้องคือคอลัมน์นี้และถ้าผมสามารถใช้มันแทน ฉันได้ทำการทดลองที่สร้างตารางและเพิ่มสองสามพันแถวลบสองสามร้อยเพิ่มอีกสองสามพัน ฯลฯ และจำนวนนั้นตายเสมอ อย่างไรก็ตามฉันมีตารางหนึ่งตารางที่มีประมาณ 700 ล้านแถวและดัชนีหลายรายการ แถวในsys.partitionsสำหรับดัชนีคลัสเตอร์นั้นตายไปแล้วอีกครั้งอย่างไรก็ตามดัชนีอื่น ๆ แสดงความแตกต่างเล็กน้อย (+ -20k) ไม่มีใครรู้วิธีคำนวณแถวนี้และถ้ามันถูกต้องตามที่ปรากฏ?

4
การแบ่งพาร์ติชันตารางสำหรับเก็บข้อมูล
สถานการณ์: สองฐานข้อมูล: DB_A และ DB_Archive กับหนึ่งตารางใหญ่มากที่เรียกว่า tableA ทุกวันบันทึกที่เก่ากว่า 60 วันจะถูกลบออกจาก DB_A และย้ายไปที่ DB_Archive เป็นหลักเพื่อแยกสิ่ง "แยก" ออกเนื่องจาก tableA ถูกสอบถามอย่างหนักใน DB_A สำหรับบันทึกของ 2 เดือนที่ผ่านมา ฉันต้องการกำจัดกระบวนการนี้เพราะมันช้าและสิ้นเปลืองทรัพยากรจำนวนมาก ฉันกำลังคิดที่จะนำตารางพาร์ติชั่นไปใช้บน DB_A ด้วยฟังก์ชั่นพาร์ติชั่นในคอลัมน์วันที่และเก็บบันทึกทั้งหมด <2 เดือนในหนึ่งพาร์ติชั่นและทุกเรคคอร์ด> 2 เดือนในอีกพาร์ติชันหนึ่ง คำถามของฉัน: สถานการณ์นี้จะทำงานเป็นอย่างไรถ้าฉันมีฐานข้อมูล 2 แบบ ถ้าฉันค้นหา tableA สำหรับบันทึก> getdate () - 30 จะอ่านพาร์ติชันเก็บถาวรหรือไม่ ฉันคิดว่าฉันต้องแบ่งดัชนีด้วยใช่มั้ย ฉันจะจัดการกับความจริงที่ว่าในวันพรุ่งนี้ฟังก์ชั่นพาร์ทิชันของฉันจะ "เปลี่ยน" ฉันหมายความว่าถ้าฉันสร้างฟังก์ชั่นวันนี้ (วันที่ 2 กรกฎาคมช่วงของมันจะเป็นวันที่ 2 …

1
ผลกระทบไฟล์ดิสก์ของการลบและสูญญากาศ
ฉันมีตารางที่อัปเดตบ่อยมากที่มี 240 ล้านแถว (และเพิ่มขึ้น) ทุกๆสามชั่วโมง 1.5 ล้านแถวจะถูกแทรกและ 1.5 ล้านแถวจะถูกลบ เมื่อฉันย้ายคลัสเตอร์ไปยัง SSD เวลาแทรกจำนวนมาก (โดยใช้การคัดลอก) นี้ถูกตัดจาก 22 นาทีเป็น 2.3 นาที เวลาลบก็ดีขึ้นเช่นกัน ฉันวางแผนที่จะทำการอัปเดตจำนวนมากนี้ทุกสองชั่วโมงหรือทุกชั่วโมง แม้ว่าประสิทธิภาพในตอนนี้ (หลังจาก SSD) เข้ากันได้กับการอัปเดตบ่อยครั้งมากขึ้นฉันได้อ่านเรื่องราวสยองขวัญเกี่ยวกับการตายของ SSD เนื่องจากความอดทนของ NAND จำกัด รวมกับการขยายการเขียน เนื่องจาก SSD มีราคาแพงฉันจึงต้องการผลักดันความตายไปสู่อนาคตเท่าที่จะทำได้ ดังนั้นคำถามของฉัน: เกิดอะไรขึ้นกับไฟล์ดิสก์ในการลบและสูญญากาศที่ตามมา? ฉันเดาว่ามีการเขียนดิสก์สองรายการหนึ่งรายการเพื่อทำเครื่องหมายแถวว่าถูกลบและอีกรายการหนึ่งเมื่อดูดฝุ่นเพื่อทำเครื่องหมายว่าพร้อมใช้งานเพื่อเขียนทับ หากแทนที่การลบและการดูดฉันจะแบ่งพาร์ติชันตารางที่สร้างและวางตารางที่แต่ละส่วนแทรก / ลบจำนวนมากฉันจะลดการสึกหรอของ SSD หรือไม่

1
การสลับข้อมูลล้มเหลวด้วย“ อนุญาตค่าที่ไม่ได้รับอนุญาตจากการตรวจสอบข้อ จำกัด หรือฟังก์ชั่นพาร์ติชันบนตารางเป้าหมาย”
รับดังต่อไปนี้ -- table ddl create table dbo.f_word( sentence_id int NULL, sentence_word_id int NULL, word_id int NULL, lemma_id int NULL, source_id int NULL, part_of_speech_id int NULL, person_id int NULL, gender_id int NULL, number_id int NULL, tense_id int NULL, voice_id int NULL, mood_id int NULL, case_id int NULL, degree_id int NULL, citation …

1
ฉันจะตีความผลลัพธ์ของ DMV เหล่านี้เพื่อช่วยฉันประเมินกลยุทธ์การแบ่งพาร์ติชันของเราได้อย่างไร
เวอร์ชัน: SQL Server 2008 R2 Enterprise Edtn (10.50.4000) ในความพยายามที่จะประเมินกลยุทธ์การแบ่งพาร์ติชันของฉันฉันเขียนแบบสอบถามนี้เพื่อรับวิธีการเข้าถึงกับดัชนีในพาร์ติชัน (ในความหมายกว้างที่สุดของคำแม้ว่าฉันจะกำจัดกอง) ในขณะที่ฉัน จำกัด การโฟกัสไปที่ตารางที่แบ่งพาร์ติชันฉันเชื่อว่าฉันต้องมองrange_scan_countและsingleton_lookup_countแต่ก็มีช่วงเวลาที่ยากลำบากในการกำหนดแนวคิด SELECT t.name AS table_name, i.name AS index_name, ios.partition_number, leaf_insert_count, leaf_delete_count, leaf_update_count, leaf_ghost_count, range_scan_count, singleton_lookup_count, page_latch_wait_count , page_latch_wait_in_ms, row_lock_count , page_lock_count, row_lock_wait_in_ms , page_lock_wait_in_ms, page_io_latch_wait_count , page_io_latch_wait_in_ms FROM sys.dm_db_partition_stats ps JOIN sys.tables t ON ps.object_id = t.object_id JOIN …

1
การจัดเก็บและการสืบค้นข้อมูลการกลิ้งใน PostgreSQL
ฉันมีข้อมูลโมเดลสภาพอากาศจำนวนมากถูกใส่ลงในฐานข้อมูล PostgreSQL เครื่องมี 8 คอร์และ RAM 16 GB ฉันใช้ PostgreSQL 9.3 กับ PostGIS 2.1 แต่ละตารางจะมีข้อมูลสภาพอากาศที่แตกต่างกัน (อุณหภูมิจุดน้ำค้างลม ฯลฯ ) แต่ละตารางจะมีคอลัมน์ 6-7 คอลัมน์: ละติจูดลองจิจูดลองจิจูดเรขาคณิตระดับความสูงวันที่และเวลาที่แบบจำลองนั้นเกี่ยวข้องและค่าข้อมูลที่น่าสนใจ 1-2 รายการ ข้อมูลจะถูกสอบถามเป็นหลักสำหรับกล่อง bounding ตามเวลาและระดับความสูง จะมีประมาณ 145,757,360 แถวต่อตาราง (ข้อมูลที่เก่ากว่าตอนนี้จะไม่ถูกลบอีกต่อไป) ฉันประมาณขนาดของตารางโดยประมาณประมาณ 10 GB โดยไม่มีดัชนี (นั่นคือข้อมูล 52 ไบต์บวก 23 ไบต์ค่าใช้จ่ายต่อแถว) ข้อมูลจะถูกอัปเดต / แทรกเป็นประจำเมื่อมีข้อมูลโมเดลใหม่ บันทึก: ดังนั้นฉันดูที่แผนสองข้อนี้: เพียงจัดทำดัชนีและจัดกลุ่มตาม (วันที่และเวลา, ระดับความสูง) พร้อมดัชนีเพิ่มเติมสำหรับรูปทรงเรขาคณิตของจุด รันงาน …

1
ข้อ จำกัด ของพาร์ติชันที่ไม่ได้ใช้สำหรับการรวมที่เกี่ยวข้องกับตารางที่แบ่งพาร์ติชันโดยการประทับเวลา
ฉันมีโครงสร้างตารางที่แบ่งพาร์ติชันเช่น: CREATE TABLE measurements ( sensor_id bigint, tx timestamp, measurement int ); CREATE TABLE measurements_201201( CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval)) )INHERITS (measurements); CREATE INDEX ON measurements_201201(sensor_id); CREATE INDEX ON measurements_201201(tx); CREATE INDEX ON measurements_201201(sensor_id, tx); .... …

3
ทำไมไม่แบ่งพาร์ติชัน?
เมื่อใดที่ไม่ต้องการแบ่งพาร์ติชันฐานข้อมูล (คิดMySQL แบ่ง ) ในกรณีของฉัน ฉันจะเริ่มต้นด้วยสองสามล้านแถวก็ควรเติบโตจากที่นั่น คีย์หลักในฟิลด์อักขระที่ทำหน้าที่เป็นตัวยับยั้งเคียวรีที่พบบ่อยที่สุด (และการค้นหาบ่อยครั้ง - อย่างน้อยสองสามต่อวินาที) คีย์หลักจะถูกแฮชเพื่อใช้เป็นพาร์ติชันคีย์ การอัปเดตจะทำกับทุกแถวที่ถูกดึงในคิวรีที่พบบ่อยที่กล่าวถึงข้างต้น การค้นหาน้อยลง (เทียบกับคอลัมน์วันที่หรืออื่น ๆ ) จะต้องกดพาร์ทิชันทั้งหมด แม้แต่ในจุดสุดท้ายการค้นหาไม่ทำงานคู่ขนานดังนั้นในทุกกรณีนี่คือชัยชนะหรือไม่ ข้อเสียของการแบ่งพาร์ติชั่นคืออะไร ทำไมมันไม่ได้เป็นสิ่งที่ทุกคนใช้เป็นค่าเริ่มต้นอย่างน้อยเมื่อคุณดูที่บันทึกนับล้าน + อัปเดต - ฉันเลือกคำตอบของ zgguy แต่ทราบว่าฉันได้เพิ่มคำตอบของตัวเองพร้อมกับผลการวิจัยของตัวเองรวมถึงลิงค์ไปยังคำตอบที่ดีจริงๆสำหรับคำถามที่คล้ายกันซึ่งเป็นประโยชน์อย่างมากสำหรับฉัน

2
การแบ่งพาร์ติชัน SQL Server 2008 R2 - FileGroup เดียวกัน, 1 ไฟล์, 2 partition_numbers - ช่วยเหลือ
เป็นครั้งแรกที่ฉันแบ่งพาร์ติชันใน SQL Server ฉันเรียนรู้จากคู่มือ Brent Ozar ซึ่งยอดเยี่ยม :) สองสามครั้งที่ฉันได้พบกับสถานการณ์แปลก ๆ เมื่อฉันวิ่ง: SELECT * FROM ph.FileGroupDetail ORDER BY partition_number Go มีกลุ่มไฟล์เดียวกันแสดงสองครั้งโดยมี 2 partition_numbers ที่แตกต่างกัน 1 อย่างถูกต้องในตอนท้ายด้วยค่าช่วงอื่น ๆ ที่เริ่มต้นด้วย null range_value คลิกที่นี่เพื่อดูภาพขยาย คำถามสองข้อ: สิ่งนี้เกิดขึ้นได้อย่างไรฉันไปผิดที่ไหน ฉันจะแก้ไขปัญหานี้ได้อย่างไรซึ่งหมายถึงวิธีกำจัดอย่างใดอย่างหนึ่งในตอนเริ่มต้นเนื่องจากฉันมีพาร์ติชันว่างเปล่าที่จุดเริ่มต้น ฉันพยายามลบไฟล์ (ทำงานเมื่อมันว่างเปล่า) และ filegroup แต่ filegroup บอกว่าไม่สามารถลบได้ มีใครช่วยอธิบายได้ว่าเรื่องนี้เกิดขึ้นได้อย่างไรและจะกำจัดรายการพาร์ติชั่น 2 ได้อย่างไร?

2
การแบ่งพาร์ติชันบนกลุ่มไฟล์เดียว
ฉันมีตารางที่มีขนาดใหญ่มากในฐานข้อมูลของฉัน แต่ข้อมูลจำนวนมากนี้เป็น "เก่า" เนื่องจากสถานการณ์ที่อยู่นอกเหนือการควบคุมของฉันฉันไม่ได้รับอนุญาตให้ลบข้อมูล "เก่า" นี้ ข้อ จำกัด อื่น ๆ คือฉันไม่สามารถแก้ไขฐานข้อมูลหมายถึงเพิ่มกลุ่มไฟล์ลงในนั้น ทุกอย่างอยู่ในPRIMARYกลุ่มไฟล์ ฉันคิดว่าจะแบ่งพาร์ติชันตารางเหล่านี้ออกเป็นพาร์ติชั่นบางตัวเช่น "ใหม่", "เก่า", "เก็บถาวร" และที่คล้ายกัน ฉันมีคอลัมน์ "สถานะ" ที่ฉันต้องการใช้เพื่อจุดประสงค์นี้ จากสถานการณ์และข้อ จำกัด ที่อธิบายไว้ฉันสงสัยว่าการแบ่งพาร์ติชันเหมาะสมหรือไม่ กล่าวอีกนัยหนึ่งถ้าตารางของฉันถูกแบ่งพาร์ติชั่นด้วยวิธีนี้ แต่ทุกพาร์ติชั่นอยู่ในกลุ่มไฟล์เดียวกัน SQL Server จะฉลาดพอที่จะหาพื้นที่พิเศษในไฟล์ต้นแบบที่ข้อมูล "ใหม่" ของฉันอยู่และไม่ได้สัมผัส พื้นที่ที่มีข้อมูล "เก่า" หรือไม่ ถ้าจะให้แตกต่างกันถ้าสมมุติว่า 80% ของข้อมูลของฉันคือ "เก่า" SQL Server มีกลไกในการหลีกเลี่ยงการเข้าถึงไฟล์ต้นแบบ 100% หรือไม่และเข้าถึงได้เพียง 20% ซึ่งมีข้อมูล "ใหม่" (ซึ่งแน่นอนว่าฉันระบุคอลัมน์การแบ่งพาร์ติชันในส่วนWHEREคำสั่ง) ฉันเดาว่าจะตอบคำถามนี้ใครจะต้องเข้าใจว่าการแบ่งพาร์ติชั่นนั้นดำเนินการภายในอย่างไร ฉันขอขอบคุณพอยน์เตอร์ใด ๆ

1
การแบ่งพาร์ติชัน MySQL: มีการแลกเปลี่ยนประสิทธิภาพระหว่างจำนวนพาร์ติชันและขนาดของแต่ละพาร์ติชันหรือไม่?
ฉันมีตารางขนาดใหญ่ (หลายร้อยล้านแถว) ที่ฉันต้องการแบ่งพาร์ติชันอย่างมีประสิทธิภาพ คำถามของฉันคือว่ามีการแลกเปลี่ยนระหว่างขนาดพาร์ติชันและจำนวนพาร์ติชัน เท่าที่ฉันเข้าใจแบบสอบถามส่วนใหญ่ในคอลัมน์ที่ใช้ในพาร์ติชันจะเร็วขึ้นเนื่องจากแบบสอบถามจะ (สำหรับการค้นหาส่วนใหญ่) เท่านั้นที่จะต้องค้นหาภายในพาร์ติชันที่ใช้กับแบบสอบถาม ดังนั้นมันจะทำให้รู้สึกว่าในการเพิ่มประสิทธิภาพสูงสุดคุณควรแบ่งตารางใหญ่เป็นจำนวนพาร์ติชันสูงสุดทำให้แต่ละพาร์ติชันมีขนาดเล็กที่สุด ในกรณีของ MySQL หมายถึง 1024 พาร์ติชัน แต่มีข้อเสียเปรียบด้านประสิทธิภาพใด ๆ ที่มีพาร์ติชั่นจำนวนมาก? เป็นเช่นนั้นเราจะหาจำนวนพาร์ติชั่นที่เหมาะสมได้อย่างไร? หมายเหตุ: มีคำถามที่ค่อนข้างคล้ายกันเกี่ยวกับ stackoverflow อยู่แล้วแต่มีเพียงหนึ่งคำตอบซึ่ง (จากมุมมองของฉัน) คิดถึงเครื่องหมาย ดังนั้นฉันจะระบุคำถามในแบบของฉันเอง ... หวังว่ามันจะชัดเจนยิ่งขึ้น

4
การแบ่งพาร์ติชันเซิร์ฟเวอร์ SQL - สิ่งที่ต้องใช้สำหรับพาร์ติชันคีย์?
ฉันไม่เคยทำงานกับการแบ่งพาร์ติชันของเซิร์ฟเวอร์ SQL แต่ขณะนี้ฉันต้องเผชิญกับการออกแบบฐานข้อมูลซึ่งอาจรับประกันไดรฟ์ ระบบนี้ใช้สำหรับคูปอง คูปองจะออกเป็นระยะโดยปกติทุก ๆ หกสัปดาห์แม้ว่าจะมีการออกโฆษณาแบบเฉพาะกิจเช่นสำหรับกิจกรรมพิเศษ มีลูกค้า 15 ล้านคนและสำหรับการออกแต่ละครั้งลูกค้าทุกคนจะได้รับคูปอง 6 ประเภทที่แตกต่างกันโดยมีคูปองรวม 90 ล้านใบ เราจำเป็นต้องติดตามข้อมูลการแลกรับอินสแตนซ์คูปองและเก็บรักษาไว้เป็นเวลา 6 เดือนถึงแม้ว่าโดยทั่วไปแล้วคูปองจะใช้ได้เพียงหกสัปดาห์เท่านั้น คำขอแลกรางวัลใด ๆ สำหรับคูปองที่ไม่ถูกต้องจะไม่สามารถเข้าถึงฐานข้อมูลได้เพราะจะทำการตรวจสอบโดย POS จนถึง ในช่วงเวลาหกเดือนเราจะต้องเก็บแถวได้ 360 ล้านแถวในตารางอินสแตนซ์คูปองและมากถึง 72 ล้านแถว (สมมติว่ามีอัตราการไถ่ถอนสูงสุด 20%) ในตารางแลกซื้อ ฉันรู้สึกว่าตัวเลขเหล่านี้ใหญ่เกินไปสำหรับพาร์ติชันเดียวหรือไม่ คำถามของฉันคืออะไรใช้เป็นคีย์พาร์ติชัน หนึ่งในผู้สมัครที่เห็นได้ชัดคือการออกงานโดยให้พาร์ทิชั่นประมาณ 6 ครั้ง แต่ฉันคิดว่าอาจเป็นไปได้ว่าขนาดพาร์ทิชันที่ใหญ่เกินไปที่จะให้มีประสิทธิภาพสูงสุด? มันจะเป็นไปได้ที่จะแบ่งพาร์ติชันด้วยสองปุ่มเช่นโดยการออกอีเวนต์ + ตัวเลขสุดท้ายของรหัสลูกค้าหรือไม่ ดังนั้นตรรกะจะเป็น: If issuance event = 1 and last digit of customer …

2
วิธีการป้องกัน Deadlocks ของคอลัมน์ที่แบ่งพาร์ติชันบน SELECT
ฉันมีตารางดัชนีคอลัมน์หลัก (CCI) สามตารางใน SQL Server 2016 CCI ทั้งหมดเหล่านี้อยู่ในรูปแบบการแบ่งพาร์ติชันเดียวกันโดยยึดตาม ID ผู้เช่า เมื่อเร็ว ๆ นี้และไม่สอดคล้องกันฉันได้รับการหยุดชะงักในงบเลือกง่าย ๆ จากการเข้าร่วมตารางเหล่านี้ ตัวอย่างแบบสอบถามที่ deadlocks: SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 ข้อความผิดพลาด: ทรานแซคชัน …

1
สร้างดัชนีออฟไลน์ใหม่บนตารางที่แบ่งพาร์ติชัน
ถ้าฉันตารางพาร์ทิชันด้วยntext, textหรือimageประเภทข้อมูลและสร้างดัชนีบนพาร์ติชันเดียวที่มีonline = offไม่ว่าล็อคตารางทั้งหมดหรือเพียงแค่พาร์ทิชันในคำถาม?

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