D'après ce que j'ai compris, la documentation indique qu'elle ne stockera pas de littéral "-" caractère , ce qui signifie qu'il fait probablement maintenant ce que les autres champs signés INTEGER ont toujours fait et qu'il stocke un bit de signe pour indiquer les nombres négatifs à la place.
Vous voyez toujours un signe moins devant le nombre car il est généré par MySQL à la suite de ce bit de signe.
Si vous ne comprenez pas le bit de signe, vous pouvez considérer comment un octet signé peut stocker des nombres de -128 à 127, tandis qu'un octet non signé peut stocker des nombres de 0 à 255. C'est parce que l'un des 8 bits d'un nombre signé est étant utilisé pour stocker +/- (1 est négatif, 0 est positif), tandis que les bits restants offrent des nombres jusqu'à 2^7 (-128 ou 127).
Ainsi, par exemple, si les bits 1111 avaient un bit de signe, ils seraient égaux à -7 (négatif + 4 + 2 + 1), mais s'ils n'étaient pas signés, ils seraient égaux à 15 (8 + 4 + 2 + 1). C'est toujours la même quantité de bits stockés.
Vous vous demandez peut-être pourquoi la borne négative dans un nombre signé peut utiliser le 8e bit, alors que la borne positive est limitée à la somme des 7 bits (1 de moins que le 8e bit). En effet, 10000000 est considéré à la fois comme négatif et le 8e bit simultanément, car sa représentation de -0 est autrement redondante avec 00000000 qui représente 0. Il n'y a pas de distinction entre zéro négatif et positif, donc un bit négatif le plus significatif est toujours la valeur de ce bit lui-même (mais négatif).
