varchar (255) เทียบกับ tinytext / tinyblob และ varchar (65535) เทียบกับ blob / text


92

ตามความหมาย:

VARCHAR: ช่วงของความยาวคือ 1 ถึง 255 อักขระ ค่า VARCHAR จะถูกจัดเรียงและเปรียบเทียบในรูปแบบที่ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่เว้นแต่จะมีการระบุคีย์เวิร์ด BINARY x + 1 ไบต์
TINYBLOB, TINYTEXT: คอลัมน์ BLOB หรือ TEXT ที่มีความยาวสูงสุด 255 (2 ^ 8 - 1) อักขระ x + 1 ไบต์

จากสิ่งนี้ฉันจึงสร้างตารางต่อไปนี้:

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255),
  `lastname` tinytext,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

หรือจะดีกว่าถ้าสร้าง varchar หรือ tinytext และทำไม ?

มันเหมือนกันสำหรับ:

VARCHAR: ช่วงของ Length คือ> 255 อักขระ ค่า VARCHAR จะถูกจัดเรียงและเปรียบเทียบในรูปแบบที่ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่เว้นแต่จะมีการระบุคีย์เวิร์ด BINARY x + 2 ไบต์
BLOB, TEXT A BLOB หรือคอลัมน์ TEXT ที่มีความยาวสูงสุด 65535 (2 ^ 16 - 1) อักขระ x + 2 ไบต์


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

คำตอบ:


10

ในกรณีนี้varcharจะดีกว่า

โปรดทราบว่าvarcharอาจมีตั้งแต่ 1 ถึง 65535 ตัวอักษร

ค่าในคอลัมน์ VARCHAR เป็นสตริงที่มีความยาวผันแปรได้ ความยาวสามารถระบุเป็นค่าตั้งแต่ 0 ถึง 255 ก่อน MySQL 5.0.3 และ 0 ถึง 65,535 ใน 5.0.3 และเวอร์ชันที่ใหม่กว่า ความยาวสูงสุดที่มีประสิทธิภาพของ VARCHAR ใน MySQL 5.0.3 และใหม่กว่านั้นขึ้นอยู่กับขนาดแถวสูงสุด (65,535 ไบต์ซึ่งแบ่งใช้ระหว่างคอลัมน์ทั้งหมด) และชุดอักขระที่ใช้ ดูส่วน E.7.4“ การนับคอลัมน์ตารางและขีด จำกัด ขนาดแถว”

Blobs จะถูกบันทึกไว้ในส่วนแยกต่างหากของไฟล์
ต้องมีการอ่านไฟล์เพิ่มเติมเพื่อรวมไว้ในข้อมูล
ด้วยเหตุนี้ varchar จึงดึงข้อมูลได้เร็วกว่ามาก

หากคุณมีหยดขนาดใหญ่ที่เข้าถึงได้ไม่บ่อยนัก
การจัดเก็บข้อมูลหยดในไฟล์แยกต่างหาก (ส่วนหนึ่งของไฟล์) ช่วยให้ไฟล์ข้อมูลหลักของคุณมีขนาดเล็กลงและดึงข้อมูลได้เร็วขึ้น


จะดีกว่าหรือไม่นั้นขึ้นอยู่กับรูปแบบการเข้าถึงข้อมูลของคุณ
Michael Mior

1
ไฟล์ที่แยกจากกันอาจเป็นไฟล์ใด
glglgl

1
Blobs ไม่ได้บันทึกในไฟล์แยกต่างหาก แต่จะถูกเก็บไว้ในตำแหน่งทางกายภาพแยกต่างหากจากส่วนที่เหลือของคอลัมน์
Michael Mior

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

1
ฉันยังสงสัยว่าไฟล์ที่ไม่ได้ใช้คอลัมน์นี้อาจมีประสิทธิภาพมากกว่าหากข้อมูลถูกจัดเก็บไว้นอกหน้าแม้ว่าฉันไม่แน่ใจว่าเครื่องมือเพิ่มประสิทธิภาพการสืบค้นนั้นฉลาดพอที่จะไม่ดึงข้อมูลนี้
Michael Mior
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.