d******a
发帖数: 32122 | 1 ＳＱＬ Ｓｅｒｖｅｒ里，Ｖａｒｃｈａｒ（ｎ），ｎ最大８０００
ｎ＜＝９００的时候可以做ｉｎｄｅｘ，那么为什么会有ｖａｒｃｈａｒ（１０）之类的
统一做个缺省的ｖａｒｃｈａｒ（８００）不就得了？
在小于９００的前提下，小ｎ究竟比大ｎ有什么优势？ | g***l
发帖数: 18555 | 2 如果我记得不错，VARCHAR是用POINTER，不是直接存储在TABLE里的，虽然VARCHAR的空
间是可变的，你告诉存储每个80这样存储起来比较容易。比如有一百万RECORD，一百万
个火柴盒好管理好SEARCH呢，还是一百万个火柴盒和摩天大楼的混合体好存贮好SEARCH
呢，结论很清楚的。 | S*****0
发帖数: 538 | 3 An index can't be built more than 900 bytes.
In SQL Server, the maximum length for a record is 8060 bytes. If a records
is larger than 8000 (for example, VARCHAR(MAX)), it will be placed on a text
or LOB storage. Someone did a test, and MAX-type column is about 10% skower
than non-MAX-type colum in performance.
To answer your question regarding to the 800 bytes vs 10 bytes. For sure,
the smaller, the better. More data in a data page, more data in memory/cache.
类的
【在 d******a 的大作中提到】
: ＳＱＬ Ｓｅｒｖｅｒ里，Ｖａｒｃｈａｒ（ｎ），ｎ最大８０００
: ｎ＜＝９００的时候可以做ｉｎｄｅｘ，那么为什么会有ｖａｒｃｈａｒ（１０）之类的
: 统一做个缺省的ｖａｒｃｈａｒ（８００）不就得了？
: 在小于９００的前提下，小ｎ究竟比大ｎ有什么优势？
| y****9
发帖数: 144 | 4 I don't think this is a valid explanation, bcoz varchar(800) won't use 10
times more storage than varchar(80). Based on BOL,
varchar [ ( n | max ) ]
Variable-length, non-Unicode character data. n can be a value from 1 through
8,000. max indicates that the maximum storage size is 2^31-1 bytes. The
storage size is the actual length of data entered + 2 bytes. The data
entered can be 0 characters in length. The ISO synonyms for varchar are char
varying or character varying.
So if I know my data will be < 80 bytes, instead of declare varchar(80),
what could be worse if i just declare varchar(800) ? I understand the
orignial question in this way. I am not sure the answer
cache. | c*****t
发帖数: 1879 | 5 不清楚 SQL Server，但是俺从其他系统的角度来说一下。
每个 row 的最大是有限制的。比如说 32-64K 。这样的话，该 row 才有可
以放进一个 data block 里面。data block 是数据库的一个基本储存单位。
这个限制平常看不出来，但是当某个 table 有 1000 column 的话，就体现
出来了。数据库需要考虑到最糟糕的情况，所以如果超过了 row size limit，
就可以拒绝接受该 create table 。这时候就需要对 varchar 的长度精打细算。
PostgreSQL 里面的 text 是介于 varchar 和 clob 之间。当 text 的长度
较小的时候，该文字可以放进 row 里面。较大的时候（比如超过 2000），
就开始先 compress 一下。还是太大的话，用类似 clob 的办法存。当然
这几种办法就没有读写短的 varchar 那么快。
至于 index，其实也就是一个小点的 table ，读写的速度很重要。而越长
的 varchar 的读写也越花时间。事实上除非是 unique index，太长的
varchar 没太大的用处，因为最主要区分两个 varchar 的大多数情况下是
在开头的部分。比如说，某个 index A 里面的 varchar 平均是 800，另外
一个 index B 只取头 80 个字节。大部分情况下，使用 index B 可以快
很多，因为 IO 只有 A 的 1/10 ，而并没有增加几个重复的。所以 index
最多只取一定长度的 varchar 。
类的
【在 d******a 的大作中提到】
: ＳＱＬ Ｓｅｒｖｅｒ里，Ｖａｒｃｈａｒ（ｎ），ｎ最大８０００
: ｎ＜＝９００的时候可以做ｉｎｄｅｘ，那么为什么会有ｖａｒｃｈａｒ（１０）之类的
: 统一做个缺省的ｖａｒｃｈａｒ（８００）不就得了？
: 在小于９００的前提下，小ｎ究竟比大ｎ有什么优势？
|
|
