Maksymalna długość tekstu typu MySQL


437

Tworzę formularz do wysyłania prywatnych wiadomości i chcę ustawić maxlengthwartość pola tekstowego odpowiednią do maksymalnej długości textpola w mojej tabeli bazy danych MySQL. Ile znaków może przechowywać pole tekstowe typu?

Jeśli dużo, czy byłbym w stanie określić długość w polu typu tekstu bazy danych, tak jak w przypadku varchar?


5
Wpisujesz 64k w prostym polu tekstowym? bolesne ...
Marc B

169
@Marc B Nigdy nie lekceważ zdolności użytkownika do wklejania dużych ilości śmieci do prywatnego pola wiadomości tekstowej.
simontemplar

5
I dlatego powinieneś ograniczyć pojemność
pola tekstowego

Odpowiedzi:


750

Zobacz dla maksymalnych liczb: http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

TINYBLOB, TINYTEXT       L + 1 bytes, where L < 2^8    (255 Bytes)
BLOB, TEXT               L + 2 bytes, where L < 2^16   (64 Kilobytes)
MEDIUMBLOB, MEDIUMTEXT   L + 3 bytes, where L < 2^24   (16 Megabytes)
LONGBLOB, LONGTEXT       L + 4 bytes, where L < 2^32   (4 Gigabytes)

L to liczba bajtów w polu tekstowym. Zatem maksymalna liczba znaków dla tekstu wynosi 2 16 -1 (przy użyciu znaków jednobajtowych). Oznacza 65 535 znaków (przy użyciu znaków jednobajtowych).

Kodowanie UTF-8 / MultiByte : przy użyciu kodowania MultiByte każdy znak może zajmować więcej niż 1 bajt miejsca. W przypadku UTF-8 zużycie miejsca wynosi od 1 do 4 bajtów na znak.


2
@ fyr- Co to znaczy dla L + 2 bajtów, gdzie L <2 ^ 16? Czy mógłbyś to jeszcze zdefiniować? Poza tym możesz mi powiedzieć, ile znaków możemy przechowywać w polu tekstowym? Proszę ....
Bajrang

2
@JJ L to liczba znaków, a liczba znaków musi być mniejsza niż 2 do potęgi 16. 2 ^ 16 = 65536. Możesz więc wprowadzić 65535 znaków, które zużywają 65535 bajtów + 3 bajty = 65 538 bajtów na pełny wypełnione pole.
fyr

9
Zauważ, że limity wielkości są w bajtach . Więc jeśli używasz znaków wielobajtowych, nie otrzymujesz 2 ^ 16 znaków w kolumnie TEKST, otrzymujesz jednak tyle znaków, ile możesz przechowywać w 2 ^ 16 bajtach.
Bill Karwin

4
Co powiedział Bill Karwin. BYTES, NIE CHARAKTERY. Znak może używać 4 bajtów do przechowywania z danym kodowaniem (jak 💩 w UTF-8).
basic6

8
Zauważ, że w MySQL utf8 zużywa do 3 bajtów, utf8mb4 zużywa do 4. referencji
mpen

126

TINYTEXT: 256 bajtów
TEKST: 65 535 bajtów
MEDIUMTEXT: 16 777
215 bajtów LONGTEXT: 4 294 967 295 bajtów


10
Myślę, że TINYTEXT powinien mieć 255 bajtów zamiast 256 bajtów, zgodnie z przyjętą odpowiedzią?
cytsunny

83
Type       | Approx. Length     | Exact Max. Length Allowed
-----------------------------------------------------------
TINYTEXT   | 256 Bytes          |           255 characters
TEXT       |  64 Kilobytes      |        65,535 characters
MEDIUMTEXT |  16 Megabytes      |    16,777,215 characters
LONGTEXT   |   4 Gigabytes      | 4,294,967,295 characters

Uwaga: W przypadku używania znaków wielobajtowych (takich jak arabski, gdzie każdy znak arabski zajmuje 2 bajty), kolumna „Dopuszczalna dokładna maksymalna długość” TINYTEXTmoże zawierać maksymalnie 127 znaków arabskich (Uwaga: spacja, myślnik, podkreślenie i inne takie znaki , to znaki 1-bajtowe).

Zasadniczo wygląda to tak:

„Dopuszczalna dokładna maksymalna długość” = „Przybliżona długość” w bajtach - 1



8

Ile znaków może przechowywać pole tekstowe typu?

Zgodnie z dokumentacją, jeśli zestaw znaków to UTF8, możesz użyć maksymalnie 21 844 znaków

Jeśli dużo, czy mógłbym określić długość w polu typu tekstu db tak jak w przypadku varchar?

Nie musisz określać długości. Jeśli potrzebujesz więcej znaków, użyj typów danych MEDIUMTEXT lub LONGTEXT. W VARCHAR określona długość nie jest wymagana do przechowywania, dotyczy tylko sposobu pobierania danych z bazy danych.


8
TINYTEXT 256 bytes
TEXT 65,535 bytes ~64kb
MEDIUMTEXT 16,777,215 bytes ~16MB
LONGTEXT 4,294,967,295 bytes ~4GB

TINYTEXTto ciąg danych typu, który może przechowywać do 255znaków.

TEXTto ciąg danych typu, który może przechowywać do 65,535znaków. TEXTjest powszechnie używany do krótkich artykułów.

LONGTEXTto ciąg danych o maksymalnej długości 4,294,967,295znaków. Użyj, LONGTEXTjeśli chcesz przechowywać duży tekst, na przykład rozdział powieści.


1

TEXTto ciąg danych typu, który może przechowywać do 65 535 znaków. Ale jeśli chcesz przechowywać więcej danych, zmień typ danych naLONGTEXT

ALTER TABLE name_tabelZMIANA text_fieldlongtext CHARACTER SET utf8UKŁADAJ utf8_general_ciNOT NULL;


1

Dla MySql w wersji 8.0.

Wymagania numeryczne dotyczące przechowywania

Data Type       Storage Required
TINYINT         1 byte
SMALLINT        2 bytes
MEDIUMINT       3 bytes
INT, INTEGER    4 bytes
BIGINT          8 bytes
FLOAT(p)        4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT           4 bytes
DOUBLE, REAL    8 bytes
DECIMAL(M,D), NUMERIC(M,D)  Varies; see following discussion
BIT(M)  approximately (M+7)/8 bytes

Wartości kolumn DECIMAL (i NUMERIC) są reprezentowane przy użyciu formatu binarnego, który zawiera dziewięć cyfr dziesiętnych (podstawa 10) w cztery bajty. Pamięć dla liczb całkowitych i ułamkowych części każdej wartości określa się osobno. Każda wielokrotność dziewięciu cyfr wymaga czterech bajtów, a cyfry „pozostałe” wymagają ułamka czterech bajtów. Wymagane miejsce na nadmiar cyfr podano w poniższej tabeli.

Data i godzina Typ Wymagania dotyczące pamięci W przypadku kolumn TIME, DATETIME i TIMESTAMP, pamięć wymagana dla tabel utworzonych przed MySQL 5.6.4 różni się od tabel utworzonych od 5.6.4. Wynika to ze zmiany w 5.6.4, która pozwala tym typom mieć część ułamkową, która wymaga od 0 do 3 bajtów.

Data Type   Storage Required Before MySQL 5.6.4   Storage Required as of MySQL 5.6.4
YEAR        1 byte                                1 byte
DATE        3 bytes                               3 bytes
TIME        3 bytes                               3 bytes + fractional seconds storage
DATETIME    8 bytes                               5 bytes + fractional seconds storage
TIMESTAMP   4 bytes                               4 bytes + fractional seconds storage

Począwszy od MySQL 5.6.4, pamięć na ROK i DATĘ pozostaje niezmieniona. Jednak TIME, DATETIME i TIMESTAMP są reprezentowane inaczej. DATETIME jest pakowany bardziej wydajnie, wymagając 5 zamiast 8 bajtów dla części niefrakcyjnej, a wszystkie trzy części mają część ułamkową, która wymaga od 0 do 3 bajtów, w zależności od precyzji przechowywanych wartości w ułamku sekundy.

Fractional Seconds Precision    Storage Required
0                               0 bytes
1, 2                            1 byte
3, 4                            2 bytes
5, 6                            3 bytes

Na przykład CZAS (0), CZAS (2), CZAS (4) i CZAS (6) używają odpowiednio 3, 4, 5 i 6 bajtów. CZAS i CZAS (0) są równoważne i wymagają tej samej pamięci.

Aby uzyskać szczegółowe informacje na temat wewnętrznej reprezentacji wartości czasowych, zobacz MySQL Internals: Ważne algorytmy i struktury.

Wymagania dotyczące przechowywania ciągów znaków W poniższej tabeli M reprezentuje zadeklarowaną długość kolumny w znakach dla niebinarnych typów ciągów i bajtów dla ciągów binarnych. L reprezentuje rzeczywistą długość w bajtach danej wartości ciągu.

Data Type                    Storage Required
CHAR(M)                      The compact family of InnoDB row formats optimize storage for variable-length character sets. See COMPACT Row Format Characteristics. Otherwise, M × w bytes, <= M <= 255, where w is the number of bytes required for the maximum-length character in the character set.
BINARY(M)                    M bytes, 0 <= M <= 255
VARCHAR(M), VARBINARY(M)     L + 1 bytes if column values require 0  255 bytes, L + 2 bytes if values may require more than 255 bytes
TINYBLOB, TINYTEXT           L + 1 bytes, where L < 28
BLOB, TEXT                   L + 2 bytes, where L < 216
MEDIUMBLOB, MEDIUMTEXT       L + 3 bytes, where L < 224
LONGBLOB, LONGTEXT           L + 4 bytes, where L < 232
ENUM('value1','value2',...)  1 or 2 bytes, depending on the number of enumeration values (65,535 values maximum)
SET('value1','value2',...)   1, 2, 3, 4, or 8 bytes, depending on the number of set members (64 members maximum)
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.