When the database is defined to the char type field, I don't know if everyone will hesitate. Which one in char, nchar, varchar, nvarchar, text, ntext? The result is probably two kinds, one is the choice of thrift: It is best to use the length, the feeling is better than the growth can save some space, and the processing will be fast, and the length will only select the length, and will be the length Set as small as possible
The other is that it doesn't matter if it doesn't matter, try to use variable types, the length is as large as possible
.
Given the hardware like radish, the small problem of entanglement is really not much, but if you don't figure it out, you always feel that you can't afford to overweet CPUs and hard drives.
The following begins (the following instructions are only valid for SQLServer):
1. Use the following query carefully when using non-Unicode:
SELECT F from T where f = N'XX '
Cause: The index cannot be utilized because the database will convert F to Unicode and N'XX 'compare 2, CHAR and the same length VARCHAR processing speed is similar (later explanation) 3, VARCHAR does not affect processing speed ! ! ! (Looking back later) 4, the total length of the index supports up to 900 bytes, so the length of VARCHAR, CHAR and greater than 450, which are greater than 900, nchar will not be able to create index 5, text, ntext is unable to create indexed 6, the attribute type of the corresponding entity in O / R mapping is generally in String, very small with char [], so if the rationality of mapping, the type of variable length is more anabentabarized. 7, general basic information table The Name is basically all the way to use Like '% XX%' in the actual query, and this way is unable to use the index, so if you have built it for this specification, the index is built in Bai Bu 8, others like Remark The field does not need to be queried, so it is not necessary to index 9. VARCHAR storage and string are the same principle, that is, the way of length {block}, so varchar's length and its actual space is not related to 10, for Fixed length fields require additional space to store null identity, so if there is very much null in a char field, then very unfortunate, your occupied space is bigger than NULL (but this is not big too much, Because the Null ID is stored in bit, if you only have a NULL in your line, you will waste 1byte space, sin, you can use special logo, such as: 'NV '11, in the same, so for this NULL query, the index cannot be taken. If you use the null identifier, then congratulations, you can use the index 12, char and varchar's comparison costs, now The key is to look at their index lookup, because the lookup strategy is the same, therefore should be smaller than the space. In the case where the same number of characters is stored, if the quantity is small, the length of the char occupation is smaller than varchar, but if the number is slightly large, VARCHAR is completely less than char, and it is necessary to see the actual fill value, such as VARCHAR (3 ) And char (3), then theoretical should be Char fast, but if it is char (10) and varchar (10), if it is only 30% of the charge, it should be VARCHAR. Because VARCHAR needs additional space storage block length, as long as Length (1-FillFactor) is greater than this storage space (it seems to be 2 bytes), it will be faster than the same length. 13, nvarchar is slower than VARCHAR, and it will take a double space for non-Unicode characters, then this type is pushing out? Yes, for internationalization, for the Unicode type data, the sorting rules do not work, rather than Unicode characters must specify the sort rules to work normally, so n type is like this. .
