Việc đối chiếu chỉ tạo sự khác biệt nếu bạn cần ORDER BY hoặc tìm kiếm cột. Các mục được mã hóa base64 này có thể sẽ không được tìm kiếm hoặc sắp xếp.
Nếu mục được mã hóa của bạn được đảm bảo để được ít hơn 64K byte chiều dài, xác định cột của bạn như thế này:
`columnname` TEXT CHARACTER SET ascii,
Đây chính là điều cần thiết cho một biến mã hóa base64; quá trình mã hóa biến mọi thứ thành ASCII có thể hiển thị.
Nếu các mục có độ dài dưới 16 megabyte, nhưng một số sẽ dài hơn 64k, hãy sử dụng MEDIUMTEXT thay vì TEXT.
Chỉnh sửa năm sau đó.
Các OQ mã hóa chuỗi, giải mã, là một đối tượng php serialized:
a:2:{s:20:"Type_of_organisation";s:20:"Member of Parliament";s:8:"Postcode";s:7:"PE1 1JA";}
Quan sát 1: rất nhiều thứ này được lưu trữ trong các cột văn bản mà không mã hóa nó, sử dụng utf8 hoặc utf8mb4 bộ ký tự. Rất nhiều? Vâng. WordPress lưu trữ dữ liệu tùy chọn theo cách này.
Quan sát 2: Nếu nó có thể được dịch sang JSON, bạn có thể sử dụng kiểu dữ liệu JSON trong các phiên bản MySQL gần đây. Các tìm kiếm JSON vẫn không thể sargable, nhưng chúng được cấu trúc.
Nguồn
2013-08-13 01:10:38
Vì đã * đã * base64, tại sao không chỉ là CHAR/VARCHAR? BINARY, VARBINARY và BLOB là những cách phù hợp - tùy thuộc - để lưu trữ dữ liệu nhị phân (không phải mã hóa base64). Vì nó có vẻ là một giá trị nhỏ, tôi sẽ đề nghị BINARY so với BLOB. – user2246674
rực rỡ, vì một lý do nào đó tôi không nghĩ đến việc sử dụng Nhị phân! :) –
Ah, đôi khi tôi muốn giải mã những thứ được đăng trên SO. Lưu ý rằng với loại cấu trúc đó, sẽ rất rắc rối khi truy vấn đúng dữ liệu nhất định. – HamZa