varchar(255)和varchar(50)是一样的？？

时间：2021-06-22 16:05:52
比如我有一个字段，大概字节长度是30－50
听同事说，我定义varchar(255)和varchar(50)是一样的，不会给数据库增加负担。

这就不懂了，那做软件还有必要设计数据库吗，大家以后做软件都定义varchar(255)，反正不增加数据库负担，郁闷，不解！！


望指教。

27 个解决方案

#1

不知道,帮你UP

#2

varchar[(n)]

长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。所输入的数据字符长度可以为零。varchar 在 SQL-92 中的同义词为 char varying 或 character varying。



存储大小为输入数据的字节的实际长度，而不是 n 个字节

#3

我也不知道作何解释.

#4

varchar(255)和varchar(50)是不一样的，长度越长，数据库文件的大小就会越大的。

#5

个人意见，支持  paoluo(一天到晚游泳的鱼) 的说法。
淡看上去， evlon(阿牛) 有一点道理。
关注

#6

我也想知道答案.

#7

uping

#8

char,可以存储1~8000个字元，一个字元一个byte,尾端的空白字元保留
 
 varchar,可以存储1~8000个字元，一个字元一个byte,尾端的空白字元保留会删除

  按 paoluo所说，varchar(255)和varchar(50)是不一样的，长度越长，数据库文件的大小就会越大

的。数据库文件应该保存的应该包括两部分，field的参数，如果没有数据之前，会占用一定的空间？

如果没有，那么按照存进30个字元的话，varchar(50)会用50个byte存储，而varchar(255)会用30个

byte来存储，这样感觉好像varchar(255)比varchar(50)更省空间呢？！


#9

个人实际应用中体会:字符串类型一般用可变型的,然后长度设置到够用就行

#10

你找一个大数据量的数据库，备份一下，看看备份文件的大小。


然后将字段的长度改长点，再备份一下，再看看备份文件的大小。

#11

哦，那倒要test一下

 另外，我也比较疑惑，同样的数据量用varchar(50），和用char(50)会是什么状况？

 关注~

#12

varchar是可变字符
char是不可变的

#13

如果平均字符小于50，那么varchar数据库会比char数据库小。

#14

全部看完了.这个问题还真没想过.我想如果平均字符小于50，那么应该varchar(50)数据库会比varchar(255)数据库小。

#15

还没确定，，，，，，郁闷

#16

不会有权威的站出来说话的啊？？？
有确定答案后救就结了啊。
等ing

#17

uping

#18

个人认为VarChar(50)和VarChar(255)区别不大，也不存在影响数据库文件大小的问题，因为VARCHAR类型本来就是可变的，只要字符均在50以内，他们基本上是不存在差别的。个人经验，在用char时能小尽可能小，用VARCHAR时一般直接就是VARCHAR(8000)，但在在设计数据库时推荐尽可能使用CHAR类型。

#19

顶

#20

用char，程序可能好控制点，但如果字符量变化大，就太浪费数据库了。

#21

关注

#22

小了难扩展,大了维护成本高
我就是这样想的,其他的我就不明白了

#23

当然不一样了，varchar为变长字符串，后边括号内为能容纳的最大字节数，如果你你输入的字节数在50以内我建议定义varchar(50)，出于性能的考虑，如果超出了就定义255的

#24

當然不一樣.varchar(255)表示最大可以存255個字符;而varchar(50)表示最大可以存50個字符.如果能夠預估到字段的最大長度,定義字段的長度最好不要超過預估的最大長度.

#25

为了不损失脑细胞，我定义varchar(999)，万事大吉。
但问题的实质还是没解决啊。等。。。

#26

郁闷，没人解决。

#27

个人认为VarChar(50)和VarChar(255)区别不大，也不存在影响数据库文件大小的问题，因为VARCHAR类型本来就是可变的，只要字符均在50以内，他们基本上是不存在差别的。个人经验，在用char时能小尽可能小，用VARCHAR时一般直接就是VARCHAR(8000)，但在在设计数据库时推荐尽可能使用CHAR类型。
---------------------------
我看到很多数据库不是这样的，都设成varchar型，这样在客户端处理时不用再去除空格啊，否则每取过去都要去一次空格才行。不知大家有否同感。？？

#1

不知道,帮你UP

#2

varchar[(n)]

长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。所输入的数据字符长度可以为零。varchar 在 SQL-92 中的同义词为 char varying 或 character varying。



存储大小为输入数据的字节的实际长度，而不是 n 个字节

#3

我也不知道作何解释.

#4

varchar(255)和varchar(50)是不一样的，长度越长，数据库文件的大小就会越大的。

#5

个人意见，支持  paoluo(一天到晚游泳的鱼) 的说法。
淡看上去， evlon(阿牛) 有一点道理。
关注

#6

我也想知道答案.

#7

uping

#8

char,可以存储1~8000个字元，一个字元一个byte,尾端的空白字元保留
 
 varchar,可以存储1~8000个字元，一个字元一个byte,尾端的空白字元保留会删除

  按 paoluo所说，varchar(255)和varchar(50)是不一样的，长度越长，数据库文件的大小就会越大

的。数据库文件应该保存的应该包括两部分，field的参数，如果没有数据之前，会占用一定的空间？

如果没有，那么按照存进30个字元的话，varchar(50)会用50个byte存储，而varchar(255)会用30个

byte来存储，这样感觉好像varchar(255)比varchar(50)更省空间呢？！


#9

个人实际应用中体会:字符串类型一般用可变型的,然后长度设置到够用就行

#10

你找一个大数据量的数据库，备份一下，看看备份文件的大小。


然后将字段的长度改长点，再备份一下，再看看备份文件的大小。

#11

哦，那倒要test一下

 另外，我也比较疑惑，同样的数据量用varchar(50），和用char(50)会是什么状况？

 关注~

#12

varchar是可变字符
char是不可变的

#13

如果平均字符小于50，那么varchar数据库会比char数据库小。

#14

全部看完了.这个问题还真没想过.我想如果平均字符小于50，那么应该varchar(50)数据库会比varchar(255)数据库小。

#15

还没确定，，，，，，郁闷

#16

不会有权威的站出来说话的啊？？？
有确定答案后救就结了啊。
等ing

#17

uping

#18

个人认为VarChar(50)和VarChar(255)区别不大，也不存在影响数据库文件大小的问题，因为VARCHAR类型本来就是可变的，只要字符均在50以内，他们基本上是不存在差别的。个人经验，在用char时能小尽可能小，用VARCHAR时一般直接就是VARCHAR(8000)，但在在设计数据库时推荐尽可能使用CHAR类型。

#19

顶

#20

用char，程序可能好控制点，但如果字符量变化大，就太浪费数据库了。

#21

关注

#22

小了难扩展,大了维护成本高
我就是这样想的,其他的我就不明白了

#23

当然不一样了，varchar为变长字符串，后边括号内为能容纳的最大字节数，如果你你输入的字节数在50以内我建议定义varchar(50)，出于性能的考虑，如果超出了就定义255的

#24

當然不一樣.varchar(255)表示最大可以存255個字符;而varchar(50)表示最大可以存50個字符.如果能夠預估到字段的最大長度,定義字段的長度最好不要超過預估的最大長度.

#25

为了不损失脑细胞，我定义varchar(999)，万事大吉。
但问题的实质还是没解决啊。等。。。

#26

郁闷，没人解决。

#27

个人认为VarChar(50)和VarChar(255)区别不大，也不存在影响数据库文件大小的问题，因为VARCHAR类型本来就是可变的，只要字符均在50以内，他们基本上是不存在差别的。个人经验，在用char时能小尽可能小，用VARCHAR时一般直接就是VARCHAR(8000)，但在在设计数据库时推荐尽可能使用CHAR类型。
---------------------------
我看到很多数据库不是这样的，都设成varchar型，这样在客户端处理时不用再去除空格啊，否则每取过去都要去一次空格才行。不知大家有否同感。？？
标签：

相关文章