TINYTEXT, TEXT, MEDIUMTEXT และ LONGTEXT ขนาดการจัดเก็บสูงสุด

796

TINYTEXT
ข้อความ
MEDIUMTEXT
LONGTEXT

ความยาวสูงสุดที่ฉันสามารถจัดเก็บในคอลัมน์ของแต่ละประเภทข้อมูลคืออะไรคือการเข้ารหัสอักขระ UTF-8

mysql innodb

26

ยกตัวอย่าง TEXT type มันสามารถมี 65535 ไบต์ของข้อมูล UTF-8 มีอักขระหลายไบต์ ดังนั้นหากคุณกรอกข้อมูลในฟิลด์โดยใช้อักขระภาษาเดนมาร์ก "Ø" เท่านั้นคุณจะได้รับ 32767 ตัวอักษรเนื่องจากอักขระ UTF-8 นั้นประกอบด้วยสองไบต์ หากคุณเติมด้วย "a" คุณจะได้รับ 65535 ตัวอักษร

— Andrew Plank

1

ลองพิจารณาการอ่านDATATYPE แบบไหนดีกว่าการใช้ TEXT หรือ VARCHAR

— Somnath Muluk

1518

จากเอกสาร :

      ประเภท | ความยาวสูงสุด
----------- + -------------------------------------
  TINYTEXT | 255 (2 ⁸ −1) ไบต์
      TEXT | 65,535 (2 ¹⁶ −1) ไบต์ = 64 KiB
MEDIUMTEXT | 16,777,215 (2 ²⁴ −1) ไบต์ = 16 MiB
  LONGTEXT | 4,294,967,295 (2 ³² −1) ไบต์ = 4 GiB

โปรดทราบว่าจำนวนตัวอักษรที่สามารถเก็บไว้ในคอลัมน์ของคุณจะขึ้นอยู่กับการเข้ารหัสอักขระ

— สะพาน
แหล่งที่มา

3

@Bridge ไม่แน่ใจว่าฉันเข้าใจ แต่นี่หมายความว่า TINYTEXT สามารถรับได้ถึง 255 อักขระใช่ไหม ???

— ltdev

9

@Lykos ใช่แล้ว - ขึ้นอยู่กับตัวละคร จากเอกสาร:

A TEXT column with a maximum length of 255 (28 – 1) characters. The effective maximum length is less if the value contains multi-byte characters.

ดูคำตอบของ Ankan สำหรับรายละเอียดเพิ่มเติม

— Bridge

4

@ aurel.g นี่คือวิธีที่คุณตอบคำถาม และฉันเห็นด้วยกับ Christophe นี่คือวิธีที่ mySQL ควรแสดงพารามิเตอร์ของมัน - แม้ว่าจะเป็นเพียงชวเลขเสริมกับ ... มุมมองข้อความแบบ arcane

— cbmtrx

1

มันอาจจะคุ้มที่จะเพิ่มว่าลำดับความสำคัญของตัวละครคือสองไบต์ (นาที 1 ฉันคิดว่า) ดังนั้นหนึ่งอาจเก็บ 10,000-50,000 ตัวละครในคอลัมน์ข้อความ ...

— วินซ์

30

เหตุใดจึงยากที่จะหาสิ่งนี้ในเอกสารมากกว่าใน stackoverflow

— Boris D. Teoharov

245

การขยายตัวของคำตอบเดียวกัน

นี้โพสต์ SOโครงร่างในรายละเอียดค่าใช้จ่ายและกลไกการจัดเก็บข้อมูล
ตามที่ระบุไว้จากจุด (1) ควรใช้ VARCHAR แทน TINYTEXT เสมอ อย่างไรก็ตามเมื่อใช้ VARCHAR จำนวนสูงสุดของขนาดข้อมูลไม่ควรเกิน 65535 ไบต์
ตามที่อธิบายไว้ที่นี่http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.htmlสูงสุด 3 ไบต์สำหรับ utf-8

นี่คือตารางประมาณการที่เข้มงวดสำหรับการตัดสินใจที่รวดเร็ว!

ดังนั้นสมมติฐานที่เลวร้ายที่สุด (3 ไบต์ต่อ UTF-8 ถ่าน) กับกรณีที่ดีที่สุด (1 ไบต์ต่อ UTF-8 ถ่าน)
สมมติว่าภาษาอังกฤษมีค่าเฉลี่ย 4.5 ตัวอักษรต่อคำ
x คือจำนวนไบต์ที่จัดสรร

xx

      Type | A= worst case (x/3) | B = best case (x) | words estimate (A/4.5) - (B/4.5)
-----------+---------------------------------------------------------------------------
  TINYTEXT |              85     | 255               | 18 - 56
      TEXT |          21,845     | 65,535            | 4,854.44 - 14,563.33  
MEDIUMTEXT |       5,592,415     | 16,777,215        | 1,242,758.8 - 3,728,270
  LONGTEXT |   1,431,655,765     | 4,294,967,295     | 318,145,725.5 - 954,437,176.6

โปรดอ้างอิงคำตอบของ Chris V เช่นกัน: https://stackoverflow.com/a/35785869/1881812

— Ankan-Zerob
แหล่งที่มา

4

อะไรคือเหตุผลของ "VARCHAR นี้ควรใช้แทน TINYTEXT" เสมอ? จะดีกว่า (เพราะมีประสิทธิภาพด้านการจัดเก็บมากกว่า) เพื่อใช้ TINYTEXT ที่เล็กลงในบางครั้งหรือไม่

— vlasits

24

@vlasits อ่านโพสต์ SO ที่รวมไว้เพื่อดูรายละเอียด (1) ประเภทข้อความทั้งหมดรวมถึง tinytext จะถูกเก็บไว้เป็นวัตถุนอกแถวซึ่งเป็นหนึ่งในค่าใช้จ่าย (2) วัตถุเหล่านี้จะถูกอ้างอิงโดยที่อยู่ 8 หรือ 16 ไบต์ ดังนั้นไม่ว่าเล็ก ๆ ของข้อความเล็ก ๆ น้อยของคุณคืออะไรคุณกำลังเพิ่มโอเวอร์เฮดที่ไม่จำเป็นนั่นก็เช่นกันสำหรับขนาดสูงสุด 255 ไบต์ เป็นที่ชัดเจนว่าควรใช้ varchar ซึ่งไม่มีค่าใช้จ่ายใด ๆ ข้างต้น

— Ankan-Zerob

4

@ Ankan-Zerob เนื่องจากปรากฏชัดเจนว่า TINYTEXT ไม่ควรใช้กับ VARCHAR เหตุผลอะไรที่ทำให้มีตัวเลือก? มีกรณีใช้งานที่คลุมเครือบ้างไหมในกรณีที่จำเป็น?

— nextgentech

4

@nextgentech มีลักษณะที่dev.mysql.com/doc/refman/5.0/en/column-count-limit.html ขนาดเร็กคอร์ดถูก จำกัด ที่ 64 KiB ตาราง จำกัด คอลัมน์ไม่เกิน 4k TINYTEXTนับ 1 ไบต์ + 8 ไบต์กับขนาดของการบันทึกในขณะที่VARCHAR(255)นับตั้งแต่วันที่ 1 ไบต์ + 255 ไบต์ถึง 2 ไบต์ + 1020 ไบต์ (4 ไบต์ UTF-8 ตัวอักษร) กับขนาดของการบันทึก

— Shi

2

ฉันชอบการแสดงขนาดฟิลด์เป็นคำ แต่ ... ปกติแล้วภาษาอังกฤษจะถือว่ามีประมาณ 5 ตัวอักษรต่อคำและยังมีอักขระเว้นวรรคที่จะเก็บไว้ อย่างไรก็ตามภาษาอังกฤษจะอยู่ใกล้กับ 1 ไบต์ต่ออักขระ UTF-8 เสมอดังนั้นฉันจะหารด้วย 6 ให้ประมาณ 40 / 10,000 / 2,700,000 / 710,000,000 คำสำหรับขนาดแตกต่างกัน ภาษาที่มีสำเนียงเช่นโปแลนด์จะมีคำน้อยกว่าเล็กน้อย กรีก, ฮิบรู, อาราบิค, ฯลฯ (ส่วนใหญ่มีลำดับ 2 ไบต์) ประมาณครึ่งหนึ่ง; อุดมคติของ CJK นั้นมี 3 หรือ 4 ไบต์ แต่ฉันไม่รู้ว่าคำนี้ยาวแค่ไหน

— ChrisV

44

เพิ่มขึ้นเป็นความท้าทายของ @ Ankan-Zerob นี่คือการประเมินความยาวสูงสุดของฉันซึ่งสามารถเก็บไว้ในข้อความแต่ละประเภทที่วัดด้วยคำ :

      Type |         Bytes | English words | Multi-byte words
-----------+---------------+---------------+-----------------
  TINYTEXT |           255 |           ±44 |              ±23
      TEXT |        65,535 |       ±11,000 |           ±5,900
MEDIUMTEXT |    16,777,215 |    ±2,800,000 |       ±1,500,000
  LONGTEXT | 4,294,967,295 |  ±740,000,000 |     ±380,000,000

ในภาษาอังกฤษ 4.8 ตัวอักษรต่อคำอาจเป็นค่าเฉลี่ยที่ดี (เช่นnorvig.com/mayzner.html ) แม้ว่าความยาวของคำจะแตกต่างกันไปตามโดเมน (เช่นภาษาพูดกับเอกสารทางวิชาการ) ดังนั้นจึงไม่มีจุดที่แม่นยำเกินไป ภาษาอังกฤษส่วนใหญ่เป็นอักขระ ASCII ไบต์เดียวโดยมีอักขระหลายไบต์เป็นครั้งคราวดังนั้นใกล้กับหนึ่งไบต์ต่อตัวอักษร ต้องมีอักขระพิเศษสำหรับเว้นวรรคระหว่างคำดังนั้นฉันจึงปัดเศษลงจาก 5.8 ไบต์ต่อคำ ภาษาที่มีสำเนียงจำนวนมากเช่นพูดว่าโปแลนด์จะเก็บคำศัพท์ได้น้อยกว่าเล็กน้อยเช่นกันเช่นภาษาเยอรมันที่มีคำที่ยาวกว่า

ภาษาที่ต้องใช้อักขระหลายไบต์เช่นกรีก, อาหรับ, ฮิบรู, ฮินดี, ไทย, ฯลฯ โดยทั่วไปต้องใช้สองไบต์ต่ออักขระใน UTF-8 การคาดเดาอย่างคร่าวๆที่ 5 ตัวอักษรต่อคำฉันได้ปัดลงจาก 11 ไบต์ต่อคำ

สคริปต์ CJK (Hanzi, Kanji, Hiragana, Katakana ฯลฯ ) ฉันไม่รู้อะไรเลย ฉันเชื่อว่าตัวละครส่วนใหญ่ต้องการ 3 ไบต์ใน UTF-8 และ (ด้วยการทำให้เข้าใจง่ายมาก) พวกเขาอาจได้รับการพิจารณาให้ใช้ประมาณ 2 ตัวอักษรต่อคำดังนั้นพวกเขาจะอยู่ที่ไหนสักแห่งระหว่างอีกสองคน (สคริปต์ CJK มีแนวโน้มที่จะต้องใช้พื้นที่เก็บข้อมูลน้อยลงโดยใช้ UTF-16 ขึ้นอยู่กับ)

แน่นอนว่าไม่สนใจค่าโสหุ้ยการจัดเก็บ ฯลฯ

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

อักขระ CJK อาจใช้ลำดับ 3 หรือ 4 ไบต์: dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html

— Raptor

8

มันดี แต่ไม่ตอบคำถาม:

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

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