Sự khác biệt giữa các loại dữ liệu MySQL VARCHAR và TEXT là gì?


19

Sau phiên bản 5.0.3 (cho phép VARCHAR là 65.535 byte và ngừng cắt các khoảng trắng ở cuối), có sự khác biệt lớn nào giữa hai loại dữ liệu này không?

Tôi đã đọc danh sách về sự khác biệt và hai lưu ý duy nhất là:

Đối với các chỉ mục trên các cột BLOB và TEXT, bạn phải chỉ định độ dài tiền tố chỉ mục. Đối với CHAR và VARCHAR, độ dài tiền tố là tùy chọn. Xem Phần 7.5.1, Chỉ mục Cột Cột.

Cột BLOB và văn bản không thể có giá trị DEFAULT.

Vì vậy, do hai hạn chế này trên kiểu dữ liệu TEXT, tại sao bạn lại sử dụng nó trên varchar (65535)? Có sự phân nhánh hiệu suất của cái này hơn cái kia không?


1
khi bạn muốn có nhiều hơn 65535 ký tự trong dữ liệu?
BlackICE

Đây là một chủ đề diễn đàn khá hay về điểm chuẩn giữa varchar và văn bản: http://forums.mysql.com/read.php?24,105964,105964
chia

Bởi vì danh sách đó thực sự làm rất tốt việc đưa ra các chi tiết rõ ràng và bởi vì bạn đã có danh sách liệt kê khác nhau, tôi không chắc đây là loại câu hỏi chúng tôi cần trên DBA. Có lý do nào mà danh sách bạn trích dẫn và lý do bạn đưa ra không đủ tốt trong trường hợp này không? Nếu không thì tôi sẽ đến VtC
jcolebrand

1
Tôi đã cập nhật câu hỏi của mình, nhưng một lý do rõ ràng mà tôi không chắc chắn là hiệu suất của cái này hơn cái kia. Không chắc chắn nếu có những lý do không rõ ràng khác
Derek Downey

Vì vậy, có công bằng không khi những gì bạn hỏi là đặc điểm hiệu suất của cái này hơn cái kia?
jcolebrand

Câu trả lời:


13

chia liên kết với một số thông tin giải thích vấn đề cơ bản (có sự khác biệt về hiệu suất), nhưng không đủ đơn giản để nói rằng cái này luôn tốt hơn cái kia. (nếu không, sẽ không có lý do để có cả hai.) Ngoài ra, trong MyISM, kích thước tối đa 64k cho VARCHAR không phải cho mỗi trường - đó là mỗi bản ghi.

Về cơ bản, có 4 cách để lưu trữ chuỗi trong các bản ghi cơ sở dữ liệu:

  1. chiều dài cố định
  2. Chuỗi kiểu C (được đánh dấu bằng NULL hoặc ký tự tương tự ở cuối chuỗi)
  3. Chuỗi kiểu Pascal (một vài byte để chỉ độ dài, sau đó là chuỗi)
  4. Con trỏ (lưu trữ chuỗi ở nơi khác)

MyISM sử dụng một cái gì đó tương tự như # 3 cho VARCHAR và một cách tiếp cận hỗn hợp cho TEXT nơi nó lưu trữ phần đầu của chuỗi trong bản ghi, sau đó phần còn lại của chuỗi ở một nơi khác. InnoDB tương tự như VARCHAR, nhưng lưu trữ trường văn bản hoàn chỉnh bên ngoài bản ghi.

Với 1 & 4, nội dung trong bản ghi luôn có cùng độ dài, do đó, việc bỏ qua sẽ dễ dàng hơn nếu bạn không cần chuỗi, nhưng cần nội dung theo sau. Cả # 2 và # 3 đều không quá tệ đối với các chuỗi ngắn ... # 2 phải tiếp tục tìm kiếm điểm đánh dấu, trong khi # 3 có thể bỏ qua phía trước ... vì các chuỗi dài hơn, # 2 trở nên tồi tệ hơn cho việc sử dụng cụ thể này trường hợp

Nếu bạn thực sự cần đọc chuỗi, số 4 chậm hơn, vì bạn phải đọc bản ghi, sau đó đọc chuỗi có thể được lưu trữ ở nơi khác trên đĩa, tùy thuộc vào cách cơ sở dữ liệu đó xử lý nó. Số 1 luôn khá đơn giản và một lần nữa bạn gặp phải các vấn đề tương tự trong đó đối với số 2 trở nên tồi tệ hơn thì chuỗi càng dài, trong khi # 3 kém hơn một chút so với số 2 đối với các chuỗi rất nhỏ, nhưng tốt hơn vì nó dài hơn.

Sau đó, có các yêu cầu lưu trữ ... # 1 luôn có độ dài cố định, do đó, nó có thể bị phình to nếu hầu hết các chuỗi không có độ dài tối đa. # 2 có thêm 1 byte; # 3 thường có thêm 2 byte nếu max length = 255, 4 byte thêm nếu tối đa 64k. # 4 có độ dài con trỏ, cộng với các quy tắc cho # 3 thông thường.

Đối với các triển khai cụ thể trong MySQL 5.1, các tài liệu cho trạng thái MyISM :

  • Hỗ trợ cho một loại VARCHAR thực sự; một cột VARCHAR bắt đầu với độ dài được lưu trữ trong một hoặc hai byte.
  • Các bảng có cột VARCHAR có thể có chiều dài hàng cố định hoặc động.
  • Tổng độ dài của các cột VARCHAR và CHAR trong một bảng có thể lên tới 64KB.

Trong khi đối với InnoDB :

  • Phần có độ dài thay đổi của tiêu đề bản ghi chứa một vectơ bit để chỉ ra các cột NULL. Nếu số lượng cột trong chỉ mục có thể là NULL là N, vectơ bit chiếm các byte CEILING (N / 8). (Ví dụ: nếu có từ 9 đến 15 cột có thể là NULL, thì vectơ bit sử dụng hai byte.) Các cột là NULL không chiếm không gian ngoài bit trong vectơ này. Phần có độ dài thay đổi của tiêu đề cũng chứa độ dài của các cột có độ dài thay đổi. Mỗi độ dài mất một hoặc hai byte, tùy thuộc vào độ dài tối đa của cột. Nếu tất cả các cột trong chỉ mục KHÔNG phải là NULL và có độ dài cố định, tiêu đề bản ghi không có phần có độ dài thay đổi.
  • Đối với mỗi trường có độ dài biến không phải NULL, tiêu đề bản ghi chứa độ dài của cột trong một hoặc hai byte. Hai byte sẽ chỉ cần nếu một phần của cột được lưu trữ bên ngoài trong các trang tràn hoặc độ dài tối đa vượt quá 255 byte và độ dài thực tế vượt quá 127 byte. Đối với cột được lưu trữ bên ngoài, độ dài hai byte biểu thị độ dài của phần được lưu trữ bên trong cộng với con trỏ 20 byte đến phần được lưu trữ bên ngoài. Phần bên trong là 768 byte, vì vậy độ dài là 768 + 20. Con trỏ 20 byte lưu trữ độ dài thực của cột.

...

cũng như rất nhiều thứ khác khi xử lý cơ sở dữ liệu, nếu bạn không chắc chắn những gì tốt nhất cho nhu cầu của mình, hãy thử điểm chuẩn với dữ liệu và cách sử dụng tương tự và xem cách chúng hoạt động.


Chủ đề được phân chia các trạng thái được liên kết rằng MySQL lưu trữ các đốm màu và trường văn bản nội tuyến forum.mysql.com/read.php?24,105964,267596#msg-267596
Michael Mior

1
Nitpick ... Đối với tất cả các mục đích thực tế, không có giới hạn 64KB trên một hàng trong cả hai Động cơ. LONGTEXTLONGBLOBlà một trường hợp tại điểm. Chuỗi kiểu C không được sử dụng bởi MySQL (mà tôi biết). InnoDB sử dụng cách tiếp cận 'lai', nhưng nó phức tạp hơn, tùy thuộc vào kích thước hàng, row_format, v.v. Việc lưu trữ các chuỗi có độ dài "cố định" hầu như không bao giờ được khuyến khích trừ khi chúng thực sự có độ dài không đổi (country_code, zip_code, v.v.) . InnoDB có 4 ROW_FORMATs; văn bản chỉ thảo luận về 1 hoặc 2 trong số đó.
Rick James

2

Khi một CHỌN cần tạo một bảng tạm thời (chẳng hạn như để sắp xếp các kết quả), nó sẽ tạo một bảng NHỚ hoặc bảng MyISAM. BỘ NHỚ hiệu quả hơn. Có những hạn chế đối với BỘ NHỚ - một là không cho phép VĂN BẢN và BLOB. Do đó, một CHỌN có thể chạy chậm hơn với văn bản so với VARCHAR.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.