MySQL: VARCHAR ขนาดใหญ่เทียบกับ TEXT

845

ฉันมีตารางข้อความใน MySQL ที่บันทึกข้อความระหว่างผู้ใช้ นอกเหนือจากรหัสทั่วไปและประเภทข้อความ (ประเภทจำนวนเต็มทั้งหมด) ฉันต้องบันทึกข้อความจริงเป็น VARCHAR หรือ TEXT ฉันตั้งค่าขีด จำกัด front-end ของ 3000 ตัวอักษรซึ่งหมายความว่าข้อความจะไม่ถูกแทรกลงใน db นานกว่านี้

มีเหตุผลในการไปกับ VARCHAR (3000) หรือ TEXT หรือไม่? มีบางอย่างเกี่ยวกับการเขียนเพียง VARCHAR (3000) ที่ให้ความรู้สึกตอบโต้ได้ง่าย ฉันเคยผ่านการโพสต์อื่น ๆ ที่คล้ายกันใน Stack Overflow แต่จะเป็นการดีที่จะได้รับมุมมองเฉพาะสำหรับการจัดเก็บข้อความทั่วไปประเภทนี้

— ทอม
แหล่งที่มา

27

ค่อนข้างเก่า แต่ฉันมาที่นี่เพราะฉันพบปัญหาที่ทำให้ฉันคิดถึงเรื่องนี้ ในกรณีของฉันแบบฟอร์มส่วนหน้าของฉันถูก จำกัด ไว้ที่ 2,000 ตัวอักษร แต่การเข้ารหัสโดยนัยในวิธีการจัดเก็บของฉันเข้ารหัสตัวละครต่างประเทศเป็นอักขระหลายตัว ดังนั้น 2,000 ของฉันก็สูงถึง 24,000 บางสิ่งบางอย่างที่ต้องคิดถึง ...

— James S

3

ฉันพบข้อความที่จะเร็วขึ้นอย่างมีนัยสำคัญสำหรับส่วนแทรกที่เกิดขึ้นพร้อมกันจำนวนมาก

— Ray S.

1

@JamesS: utf8mb4 ... >.. <

— แบ่งแยก

10

@RickJames พิจารณาโพสต์คำตอบที่ปรับปรุงแล้วแทนที่จะปิดคำถาม

— Yvette

3

@YvetteColomb - ฉันเพิ่มคำตอบ ส่วนใหญ่ผมจะชอบที่จะกำจัดของคำตอบที่ได้รับการยอมรับเพราะมันเป็นออกจากวันที่ ฉันมาที่คำถาม & คำตอบเพราะมีใครบางคนอ้างข้อมูลที่ไม่ถูกต้องโดยพูดว่า "754 upvotes ดังนั้นจะต้องถูกต้อง" ตกลงฉันจะแก้ไขคำตอบที่ได้รับการอนุมัติเช่นกัน (แม้ว่ามันจะไม่เหมาะสมก็ตาม)

— Rick James

811

TEXTและBLOB อาจถูกจัดเก็บไว้นอกโต๊ะโดยที่ตารางมีเพียงตัวชี้ไปยังตำแหน่งของที่เก็บข้อมูลจริง ที่เก็บจะขึ้นอยู่กับหลายสิ่งเช่นขนาดข้อมูลขนาดคอลัมน์ row_format และรุ่น MySQL
VARCHARจะถูกเก็บไว้ในตารางแบบอินไลน์ VARCHARเร็วกว่าเมื่อขนาดมีความเหมาะสมการแลกเปลี่ยนซึ่งจะเร็วกว่าขึ้นอยู่กับข้อมูลและฮาร์ดแวร์ของคุณคุณต้องการเปรียบเทียบสถานการณ์จริงกับข้อมูลของคุณ

— MindStalker
แหล่งที่มา

148

+1: VARCHAR (จัดเก็บแบบอินไลน์) มักจะเร็วกว่านี้หากมีการดึงข้อมูลบ่อยครั้ง (รวมอยู่ในข้อความค้นหาส่วนใหญ่) อย่างไรก็ตามสำหรับข้อมูลจำนวนมากที่ไม่ได้รับการสืบค้นตามปกติ (นั่นคือไม่ได้อ้างอิงโดยการสืบค้นใด ๆ ) จากนั้นอาจเป็นการดีกว่าถ้าไม่มีข้อมูลที่เก็บไว้แบบอินไลน์ มีขีด จำกัด สูงสุดของขนาดแถวสำหรับข้อมูลที่เก็บไว้แบบอินไลน์

— spencer7593

21

@Pacerier: ประโยชน์ที่แน่นอนของการหลีกเลี่ยงการจัดเก็บ "inline" คือการเพิ่มจำนวนแถวที่สามารถเก็บไว้ในบล็อกซึ่งหมายความว่าแถวของตารางมีจำนวนบล็อกน้อยลงในบัฟเฟอร์แคชของ InnoDB (หน่วยความจำขนาดเล็กลง) และลดลง บล็อกที่จะถ่ายโอนไปยังและจากดิสก์ (ลด I / O) แต่นี่เป็นเพียงผลประโยชน์ด้านประสิทธิภาพหากคอลัมน์ที่จัดเก็บ "ปิดแถว" ส่วนใหญ่ไม่ได้รับการอ้างอิงจากข้อความค้นหา หากคอลัมน์ "ปิดแถว" เหล่านั้นถูกอ้างอิงโดยข้อความค้นหาส่วนใหญ่ประโยชน์นั้นจะระเหยไปหมด ต้องการแบบอินไลน์หากคอลัมน์มีขนาดพอดีกับจำนวนแถวสูงสุดและมีการอ้างอิงบ่อยครั้ง

— spencer7593

231

"VARCHAR เร็วกว่าเมื่อขนาดนั้นสมเหตุสมผล" จำนวนอักขระ "สมเหตุสมผล" คืออะไร 100? 1000? 100,000?

— ทิมปีเตอร์สัน

125

คำตอบนี้ไม่ถูกต้องสำหรับ InnoDB ทั้ง VARCHAR และ BLOB / TEXT จะถูกเก็บไว้ในคอลัมน์เดียวกับคอลัมน์อื่น ๆ หากค่าของแถวที่กำหนดนั้นพอดีกับขนาดหน้ากระดาษ (16KB และแต่ละหน้าต้องมีอย่างน้อยสองแถว) หากสตริงมีขนาดใหญ่เกินไปสตริงนั้นจะล้นไปยังหน้าเพิ่มเติม ดูmysqlperformanceblog.com/2010/02/09/blob-storage-in-innodbสำหรับคำอธิบายโดยละเอียด

— Bill Karwin

14

@BillKarwin ... ถ้าฉันเข้าใจอย่างถูกต้องแล้วไม่ควรมีความแตกต่างของประสิทธิภาพระหว่างvarcharและblob/ textกับ InnoDB สำหรับรายการข้อความขนาดเล็ก? มันจะเป็นอย่างนั้นจะฉลาดที่จะเพียงแค่ทำให้ทุกประเภทและให้ DB จัดการกับล้นอินไลน์? varchartext

— ryvantage

473

คุณสามารถทำนายระยะเวลาที่ผู้ใช้ป้อนข้อมูลได้นานแค่ไหน?

VARCHAR (X)

กรณี:ชื่อผู้ใช้อีเมลประเทศชื่อเรื่องรหัสผ่าน

ข้อความ

กรณี:ข้อความ, อีเมล, ความคิดเห็น, ข้อความที่จัดรูปแบบ, html, รหัส, รูปภาพ, ลิงก์

MEDIUMTEXT

กรณี:เนื้อหา json ขนาดใหญ่, หนังสือขนาดสั้นถึงปานกลาง, สตริง csv

LONGTEXT

กรณี:หนังสือ, โปรแกรม, ไฟล์บันทึกหลายปี, แฮร์รี่พอตเตอร์และถ้วยอัคนี, บันทึกการวิจัยทางวิทยาศาสตร์

— Michael J. Calkins
แหล่งที่มา

7

ความสามารถในการคาดการณ์เป็นรายการด้านที่นี่จริงๆ ความยาวสูงสุดที่คาดหวังจริง ๆ ควรเป็นปัจจัยในการตัดสินใจ รายการที่คุณพูดถึงว่าสามารถคาดเดาได้มากขึ้นเป็นเพียงวิธีนั้นเพราะสั้นกว่ารายการอื่น

— แอนดรูว์บาร์เบอร์

29

@ andrew-ตัดผมนั่นคือจุดของฉันแม้ว่า โพสต์อื่น ๆ ทั้งหมดอธิบายได้ดีเกี่ยวกับความแตกต่าง แต่ไม่เกี่ยวกับสถานการณ์เมื่อคุณต้องเลือกระหว่างทั้งสอง ฉันพยายามชี้ให้เห็นว่าการใช้ varchar สำหรับการคาดเดาสั้น ๆ เป็นทางเลือกที่ดีและการใช้ข้อความสำหรับความยาวโดยพลการเป็นทางเลือกที่ดี

— Michael J. Calkins

1

หากคอลัมน์ทั้งหมดสั้นและคาดเดาได้ (เช่น: ที่อยู่ MAC, IMEI ฯลฯ เป็นสิ่งที่ไม่เคยเปลี่ยนแปลง) จากนั้นใช้คอลัมน์ CHAR และคุณสามารถทำให้ขนาดแถวของคุณคงที่ซึ่งควรเพิ่มความเร็วให้มากขึ้นหากใช้ MyISAM อาจเป็นไปได้ InnoDb ถึงแม้ว่าฉันไม่แน่ใจเกี่ยวกับเรื่องนี้

— แมตต์

1

@ MichaelJ.Calkins สิ่งที่เกิดขึ้นใน MySQL 5.6 ตอนนี้คุณสามารถค้นหาข้อความเต็มใน InnoDB ได้แล้ว ดูdev.mysql.com/doc/refman/5.6/en/fulltext-search.html

— PhoneixS

7

จำนวนอักขระสูงสุด: TINYTEXT: 255; TEXT: 65,535; MEDIUMTEXT: 16,777,215; LONGTEXT: 4,294,967,29

— Victor Stoddard

218

เพียงชี้แจงแนวทางปฏิบัติที่ดีที่สุด:

ข้อความที่จัดรูปแบบข้อความควรเก็บไว้เป็น TEXT เกือบตลอดเวลา
ควรเก็บแอตทริบิวต์ของสตริงเป็น VARCHAR (ชื่อผู้ใช้ปลายทางหัวเรื่อง ฯลฯ ... )

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

ข้อความเกี่ยวกับตัวเองที่บังคับให้พวกเขาไม่เกิน 3,000 ตัวอักษรคืออะไร? หากเป็นเพียงข้อ จำกัด แอปพลิเคชันโดยพลการ (เช่นสำหรับกล่องข้อความหรือบางอย่าง) ให้ใช้TEXTฟิลด์ที่ชั้นข้อมูล

— เจมส์
แหล่งที่มา

"ซึ่งยอดเยี่ยมจนกระทั่งไม่ได้" หมายความว่าอะไร? "ไม่ใช่" หมายถึงอะไร

— Pacerier

7

@Pacerier เพื่อให้คุณเห็นตัวอย่างของ "ไม่ใช่" James มีแนวโน้มที่จะ: เกี่ยวกับตัวอย่างเช่น Twitter ซึ่งเมื่อไม่นานมานี้มีการ จำกัด จำนวนอักขระสูงสุด 140 ตัวบน PMs พวกเขาตัดสินใจว่ามันไม่สมเหตุสมผลอีกต่อไปและเลือกที่จะลบขีด จำกัด นั้นอย่างสมบูรณ์ หากพวกเขาไม่ได้คิดล่วงหน้าเกี่ยวกับเรื่องนั้น (ซึ่งฉันค่อนข้างมั่นใจว่าพวกเขาอาจจะทำ ... ) พวกเขาจะได้เข้าไปมีส่วนร่วมในสถานการณ์ดังกล่าวข้างต้น

— PaulSkinner

9

ฉันเพิ่งวางฐานข้อมูลใหม่ของเราและฉันคิดว่าไม่มีใครสามารถใส่มากกว่า 2,000 ตัวอักษรลงในช่องแสดงความคิดเห็นเล็ก ๆ ของเราและจากนั้นเจมส์ก็บันทึกไว้คืนนี้มันทันใดนั้น "ไม่เป็นไร" เพราะผู้ใช้ใส่ ความคิดเห็นที่ถูกต้องมากซึ่งมีความยาว 2,600 ตัวอักษร ฉันใช้ varchar (2000) คิดว่าคงไม่นานไปกว่านี้แล้วและฉันคิดผิด ใช่มันยอดเยี่ยมจนกระทั่งมันไม่เป็นเช่นนั้น ในกรณีของเราที่ใช้เวลาเพียงไม่กี่วันในการแสดง กฎด้านล่าง Michael J. Calkins ฉันคิดว่าฉันจะใช้ต่อจากนี้ ข้อความสำหรับข้อความความคิดเห็น

— Lizardx

1

@Pacerier "ซึ่งยอดเยี่ยมจนกระทั่งไม่ยอดเยี่ยม" มันใช้งานได้เกือบตลอดเวลาและยอดเยี่ยม ... ยกเว้นสถานการณ์พิเศษที่ไม่ดีนัก

— การชดเชย จำกัด

@Pierier อีกตัวอย่างที่น่าสนใจถูกกล่าวถึงในความคิดเห็นของคำตอบที่เลือกโดยทั่วไปเขามีขีด จำกัด front-end ที่ 2,000 ตัวอักษร แต่ตัวละครที่แนะนำอยู่ในเพจรหัสที่ในความเป็นจริงใช้ไบต์มากกว่าตัวอักษรปกติฐานข้อมูลของเขาสิ้นสุดลง สำหรับอักขระ 24k เพียงเพราะเขาต้องคำนึงถึงขนาดไบต์ที่แท้จริงของอักขระที่ถูกแนะนำ

— RaptorX

32

คำเตือน: ฉันไม่ใช่ผู้เชี่ยวชาญ MySQL แต่นี่เป็นความเข้าใจของฉันเกี่ยวกับปัญหา

ฉันคิดว่าข้อความถูกเก็บไว้นอกแถว mysql ในขณะที่ฉันคิดว่า VARCHAR ถูกเก็บไว้เป็นส่วนหนึ่งของแถว มีความยาวแถวสูงสุดสำหรับแถว mysql .. ดังนั้นคุณสามารถ จำกัด จำนวนข้อมูลอื่น ๆ ที่คุณสามารถจัดเก็บในแถวโดยใช้ VARCHAR

นอกจากนี้เนื่องจาก VARCHAR เป็นส่วนหนึ่งของแถวฉันสงสัยว่าข้อความค้นหาที่ดูในฟิลด์นั้นจะเร็วกว่าการใช้ TEXT อันเล็กน้อย

— Michael Anderson
แหล่งที่มา

38

ขีดจำกัดความยาวของแถวคือ 65,535 ไบต์ [ dev.mysql.com/doc/refman/5.0/en/column-count-limit.html ] หากคอลัมน์ของคุณมีการเข้ารหัส utf8 นั่นหมายความว่าvarcharคอลัมน์3000 อักขระสามารถใช้งานได้สูงสุด 9000 ไบต์

— ม.ค. Fabry

7

อักขระ UTF-8 สามารถมีขนาดสูงสุด 4 ไบต์ดังนั้นฉันคิดว่าคุณหมายถึง 12,000 ไบต์ (เว้นแต่มีบางสิ่งที่ MySQL ที่ฉันไม่เข้าใจ)

— raylu

13

@raylu MySQL's UTF-8 คือ "fake UTF-8" ซึ่งรองรับได้เพียง 3 ไบต์ต่อตัวอักษรสูงสุดเท่านั้นดังนั้นจึงไม่มีวิธีเก็บอักขระยูนิโค้ดที่อยู่เหนือระนาบ BMP ใน UTF-8 ของ MySQL โดยตรง สิ่งนี้ได้รับการแก้ไขใน MySQL 5.5

— Pacerier

2

ฉันเชื่อว่าการยืนยันนี้ใช้ได้กับ MyISAM เท่านั้น ฉันไม่พบแหล่งที่ชัดเจน แต่ฉันเชื่อว่า InnoDB เก็บTEXTอินไลน์ไว้ในตารางด้วย

— dotancohen

2

@dotancohen ฉันพบแหล่งที่มาอธิบายว่าการจัดเก็บข้อมูลความยาวแปรผันโดยใช้ InnoDB อาจแตกต่างกัน (สามารถเก็บไว้ภายนอกหรืออินไลน์ภายในแถว) mysqlserverteam.com/externally-stored-fields-in-innodb

— KiX Ortillan

30

คำตอบสั้น ๆ : ไม่มีประโยชน์ประสิทธิภาพหรือการจัดเก็บความแตกต่าง

คำตอบยาว:

มีเป็นหลักไม่แตกต่างกัน (ใน MySQL) ระหว่างVARCHAR(3000)(หรือขีด จำกัด ขนาดใหญ่อื่น ๆ ) TEXTและ อดีตจะถูกตัดทอนที่ 3000 ตัวอักษร ; หลังจะตัดทอนที่ 65535ไบต์ (ฉันแยกความแตกต่างระหว่างไบต์และอักขระเนื่องจากอักขระสามารถมีหลายไบต์)

สำหรับข้อ จำกัด ที่มีขนาดเล็กในมีข้อดีบางกว่าVARCHARTEXT

"ขนาดเล็ก" หมายถึง 191, 255, 512, 767 หรือ 3072 CHARACTER SETเป็นต้นขึ้นอยู่กับรุ่นบริบทและ
INDEXesถูก จำกัด ในการจัดทำดัชนีคอลัมน์ที่มีขนาดใหญ่ (767 หรือ 3072 ไบต์ซึ่งขึ้นอยู่กับรุ่นและการตั้งค่า)
ตารางระดับกลางที่สร้างโดยคอมเพล็กซ์SELECTsได้รับการจัดการในสองวิธีที่แตกต่างกันคือ MEMORY (เร็วกว่า) หรือ MyISAM (ช้ากว่า) เมื่อคอลัมน์ 'ใหญ่' เกี่ยวข้องเทคนิคที่ช้ากว่าจะถูกเลือกโดยอัตโนมัติ (การเปลี่ยนแปลงที่สำคัญมาในเวอร์ชัน 8.0 ดังนั้นรายการหัวข้อนี้อาจมีการเปลี่ยนแปลง)
เกี่ยวข้องกับรายการก่อนหน้าTEXTประเภทข้อมูลทั้งหมด(ตรงข้ามกับVARCHAR) กระโดดตรงไปที่ MyISAM นั่นคือจะแย่ลงโดยอัตโนมัติสำหรับการสร้างตารางชั่วคราวกว่าเทียบเท่าTINYTEXT VARCHAR(แต่สิ่งนี้ต้องมีการอภิปรายในทิศทางที่สาม!)
VARBINARYเป็นเช่นVARCHAR; เป็นเหมือนBLOBTEXT

คัดค้านคำตอบอื่น ๆ

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

เมื่อเธรดนี้เริ่มต้นและตอบรับมีเพียงสอง "รูปแบบแถว" ใน InnoDB หลังจากนั้นไม่นานสองรูปแบบเพิ่มเติม ( DYNAMICและCOMPRESSED )

สถานที่จัดเก็บข้อมูลสำหรับTEXTและVARCHAR()จะขึ้นอยู่กับขนาดไม่ได้อยู่ในชื่อของประเภทข้อมูล สำหรับการปรับปรุงการอภิปรายของการเปิด / ปิดการบันทึกจัดเก็บข้อมูลของคอลัมน์ข้อความ / หยดขนาดใหญ่เห็นนี้

— ริคเจมส์
แหล่งที่มา

1

มีความเข้าใจที่ดีที่นี่ นี่ควรเป็นคำตอบที่ยอมรับได้

— Kosta Kontos

2

@KostaKontos - ขอบคุณสำหรับการสรรเสริญและการแก้ไขผิดพลาด เมื่อฉันเห็นความต้องการคำตอบที่ดีกว่าฉันจะเพิ่มคำตอบแม้ว่า 8 ปีและ 800 upvotes สายเกินไป

— Rick James

7

คำตอบก่อนหน้านี้ไม่ได้ยืนยันเพียงพอในปัญหาหลัก: แม้จะมีคำสั่งง่ายๆเช่น

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id)

สามารถกำหนดตารางชั่วคราวได้และหากVARCHARเกี่ยวข้องกับเขตข้อมูลนั้นจะถูกแปลงเป็นCHARเขตข้อมูลในตารางชั่วคราว ดังนั้นถ้าคุณมีตารางที่บอกว่ามี 500,000 บรรทัดที่มีVARCHAR(65000)เขตข้อมูลคอลัมน์นี้เพียงอย่างเดียวจะใช้6.5 * 5 * 10 ^ 9ไบต์ ตาราง temp ดังกล่าวไม่สามารถจัดการในหน่วยความจำและเขียนลงดิสก์ ผลกระทบที่คาดว่าจะเป็นภัยพิบัติ

แหล่งที่มา (พร้อมตัวชี้วัด): https://nicj.net/mysql-text-vs-varchar-performance/ (นี่หมายถึงการจัดการTEXTvs VARCHARใน "มาตรฐาน" (?) เอนจิ้นการจัดเก็บ MyISAM มันอาจแตกต่างจากคนอื่น ๆ เช่น InnoDB)

— แม็กซ์
แหล่งที่มา

3

InnoDB: ใช้กับรุ่น 5.7 ได้เช่นเดียวกัน ด้วย 8.0, varchar temps มีความยาวผันแปรได้

— Rick James

3

มีความแตกต่างอย่างมากระหว่าง VARCHAR และ TEXT ในขณะที่สามารถสร้างดัชนีฟิลด์ VARCHAR ได้ แต่ฟิลด์ TEXT ไม่สามารถทำได้ เขตข้อมูลประเภท VARCHAR จะถูกจัดเก็บแบบอินไลน์ในขณะที่ TEXT ถูกเก็บไว้แบบออฟไลน์มีเพียงตัวชี้ไปยังข้อมูล TEXT เท่านั้นที่ถูกจัดเก็บในเรคคอร์ด

หากคุณต้องจัดทำดัชนีฟิลด์ของคุณเพื่อการค้นหาที่เร็วขึ้นอัปเดตหรือลบมากกว่าไปหา VARCHAR ไม่ว่าจะใหญ่แค่ไหน VARCHAR (10,000000) จะไม่เหมือนกับเขตข้อมูล TEXT เนื่องจากข้อมูลทั้งสองชนิดนี้แตกต่างกันโดยทั่วไป

หากคุณใช้ฟิลด์ของคุณเพื่อการเก็บถาวรเท่านั้น
คุณไม่แคร์เรื่องการปรับความเร็วข้อมูล
คุณใส่ใจเรื่องความเร็ว แต่คุณจะใช้โอเปอเรเตอร์ '% LIKE%' ในคำค้นหาของคุณดังนั้นการจัดทำดัชนีจะไม่ช่วยอะไรมาก
คุณไม่สามารถทำนายขีดจำกัดความยาวของข้อมูลได้

ไปสำหรับ TEXT

— Viktor Joras
แหล่งที่มา

ข้อมูลที่ทำให้เข้าใจผิดบางส่วน: คอลัมน์ TEXT ไม่สามารถเป็นดัชนีได้ทั้งหมด เมื่อคุณรวมคอลัมน์ TEXT ในดัชนีคุณต้องระบุความยาว นอกจากนี้ VARCHARs ไม่สามารถจัดทำดัชนีทั้งหมดได้ในกรณีของ VARCHARs> 255 เนื่องจากมีความยาวสูงสุดในขนาดดัชนี

— eRadical

2

Varchar ใช้สำหรับข้อมูลขนาดเล็กเช่นที่อยู่อีเมลในขณะที่ Text ใช้สำหรับข้อมูลขนาดใหญ่กว่ามากเช่นบทความข่าว Blob สำหรับข้อมูลไบนารีเช่นรูปภาพ

ประสิทธิภาพของ Varchar นั้นมีประสิทธิภาพมากกว่าเพราะมันทำงานได้อย่างสมบูรณ์จากหน่วยความจำ แต่จะไม่เป็นเช่นนั้นหากข้อมูลมีขนาดใหญ่เกินไปvarchar(4000)เช่น

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

Blob ทำงานช้าลงมากดังนั้นให้ใช้เฉพาะเมื่อคุณไม่มีข้อมูลมากเช่น 10,000 ภาพซึ่งจะมีค่าใช้จ่าย 10,000 รายการ

ทำตามเคล็ดลับเหล่านี้เพื่อความเร็วและประสิทธิภาพสูงสุด:

ใช้ varchar สำหรับชื่อชื่ออีเมล
ใช้ข้อความสำหรับข้อมูลขนาดใหญ่
แยกข้อความในตารางต่าง ๆ
ใช้การเข้าร่วมด้านซ้ายแบบสอบถามใน ID เช่นหมายเลขโทรศัพท์
หากคุณกำลังจะใช้ Blob ใช้เคล็ดลับเช่นเดียวกับในข้อความ

สิ่งนี้จะทำให้ข้อความค้นหามีค่าใช้จ่ายเป็นมิลลิวินาทีในตารางที่มีข้อมูล> 10 M และขนาดสูงสุดถึง 10GB รับประกัน

— Creative87
แหล่งที่มา