java - bigint(20)、smallint(5)

Question

CREATE TABLE `idc_logistics_assign_rules` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `sp_id` bigint(20) unsigned NOT NULL COMMENT '外键关联表ID',
  `creator` varchar(255) NOT NULL COMMENT '创建人工号',
  `gmt_create` datetime NOT NULL COMMENT '创建时间',
  `modifier` varchar(255) NOT NULL COMMENT '修改人工号',
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
  `rule_name` varchar(255) NOT NULL COMMENT '规则名称',
  `rule_json_val` varchar(4096) NOT NULL COMMENT '规则JSON字符串',
  `rule_content` varchar(4096) NOT NULL COMMENT '规则中文描述',
  `type` varchar(128) NOT NULL COMMENT '类型（同机房、同城、区域内、区域外、其他）',
  `rule_lable` varchar(256) NOT NULL COMMENT '标签',
  `is_valid` char(1) NOT NULL COMMENT '是否有效（y/n），默认n',
  `is_deleted` char(1) NOT NULL COMMENT '是否删除',
  `ordering` smallint(5) unsigned NOT NULL COMMENT '排序字段',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_ordering` (`ordering`),
  KEY `idx_rule_content` (`rule_content`(255))
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COMMENT='表名';

上面是建表的SQL语句，对于其中的数据类型有不明白的地方，如下：
1.smallint(5),我看了smallint本来的范围是：

A smallint is between -32768 and 32767 signed, or 0 and 65535 unsigned.

但是加了smallint(5)之后，对它的范围并没有影响，那么加这个有什么用呢？。假如我不指定括号中的位数呢？它的默认值是要取什么值呢？
2.同理varchar(255)是表示255个字节么？如果要存中文的话，用utf8编码，算上标点符号，大概能存多少个中文汉字呢？
3.另外还有datetime这种数据类型，一般并不指定有效位数的。那么如果我要精确到秒的、精确的分的、精确到月的，数据库中是不能直接这么存的么？只能存一个完整的时间(存一个以1970开始的long型方便),然后查的时候，可以用Mysql提供的函数来过滤？？

======================================================================
在列中使用zerofill，如插入int(4),你插入1，显示0001，你插入55555，显示也是55555，插入负数显示为0000，因为mysql自动增加UNSIGNED属性 UNSIGNED不能为负数,当你插入负数时就显示0, 多操作就能理解 希望采纳

Answer 1

1 smallint, int, il n'y a aucune différence si vous définissez la longueur ou non
2 utf8 255/3 gbk 255/2
3 L'horodatage stocké dans l'heure générale, FROM_UNIXTIME(unix_timestamp ,format ) La propre conversion d'horodatage en heure de MySQL peut répondre à vos besoins

Answer 2

• Pour des choses comme int, les crochets d'octets derrière n'ont aucun effet

• Caractère comme char, la longueur du caractère est limitée entre parenthèses

Answer 3

1-Soigné et beau
2-Probablement 255/3, je ne l'ai pas étudié trop attentivement
3-Habituellement, ce sont des horodatages bigint ou des types timestamp/datetime, et PHP peut les formater lors de la sortie de la sortie n'a pas besoin d'être traité par MySQL.

Answer 4

1.La valeur par défaut de smallint est 6 en raison du bit de signe. Cela n'a aucun effet sur la plage, comment l'afficher, mais vous pouvez voir la différence en ajoutant ZEROFILL après SMALLINT(3)
2.varchar(255) représente 255 caractères, pas des octets, ceci Vous pouvez expérimenter, mais certains les gens disent que l'ancienne version est composée d'octets. S'il s'agit d'un caractère, vous pouvez stocker 255 caractères chinois et les octets sont de 255/3, car un caractère chinois est un caractère et un caractère compte pour 3 octets en UTF8.
3. C'est principalement parce que vous divisez l'heure en arrière-plan. Vous pouvez ajouter quelques champs supplémentaires pour l'année, le mois, le jour, l'heure, la minute et la seconde. Bien entendu, mysql a également des fonctions qui peuvent être traitées, telles que : HOUR(time), SECOND(time), MOIS(time)

Answer 5

1. Comme d'autres l'ont dit, les nombres entre parenthèses ne sont que des nombres à remplir et n'ont aucun effet sur la plage de valeurs représentée par le champ. Ce nombre à remplir ne sera utilisé que lorsque vous définissez le champ sur un remplissage à zéro. . Reflétez la différence ;
2. Faites simplement un petit test vous-même, qui sera discuté ci-dessous
3. Si la quantité de données est importante et que le champ de date est l'une des conditions de requête, ce sera mieux ; pour utiliser le stockage d'horodatage, sinon utilisez date, datetime et timestamp selon vos besoins, ou ajoutez des champs tels que l'année (smallint), le mois (tinyint), le jour (tinyint) selon vos besoins. ;

Concernant les questions 1 et 2, j'ai créé un nouveau tableau et fait un test, comme suit :

CREATE TABLE `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(4) unsigned zerofill DEFAULT NULL,
  `b` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT;

INSERT INTO test
(a, b)
VALUES
(1, '1234567890'),
(11, '零一二三四五六七八九');

Résultat :

mysql> select * from test;
+----+------+--------------------------------+
| id | a    | b                              |
+----+------+--------------------------------+
|  1 | 0001 | 1234567890                     |
|  2 | 0011 | 一二三四五六七八九零           |
+----+------+--------------------------------+
2 rows in set (0.01 sec)

Mais le comportement suivant dépendra des paramètres de sql_mode, par exemple :
écrit un enregistrement dans lequel la longueur de la valeur b est 11,

INSERT INTO test
(b)
VALUES
('一二三四五六七八九零一');

Je peux écrire dans une base de données locale sans erreur, mais les données stockées sont 一二三四五六七八九零, ce qui signifie que plus de 10 chiffres de données seront effacés
mais dans une autre base de données locale ; a trouvé une erreur, signalant Data too long for column 'b' at row 1.
Grâce à SELECT @@sql_mode;, nous avons constaté que ce dernier a un STRICT_TRANS_TABLES supplémentaire, ce qui provoque le signalement d'une erreur lors de la tentative d'écriture de données qui ne répondent pas à la définition ddl.

Référence : https://dev.mysql.com/doc/ref...