Relationships between char, varchar, varchar2, nvarchar in the database

The string "abc", for Char (20), means that the characters you store will account for 20 bytes (including 17 null characters), while the same VARCHAR2 (20) occupies only 3 bytes of length, 20 is the maximum value, and when you store characters less than 20 o'clock, the actual length is stored.

Oracle, there will be a varchar2 type of data type, the difference between the VARCHAR2 type and the varchar type:

1, varchar2 all the characters accounted for two bytes processing (under normal circumstances), varchar only for Chinese characters and full-width character two bytes, numbers, English characters, etc. are a byte;
2, VARCHAR2 the empty string equivalent to NULL processing, and varchar is still in accordance with the empty string processing;
3, VARCHAR2 characters to be stored in a few bytes, to see the character set used by the database,
The VARCHAR2 type is recommended in most cases to ensure better compatibility.

varchar (n), n in nvarchar (n) how to interpret:
nvarchar (n) can store up to n characters without distinguishing between Chinese and English.
VARCHAR (n) can store up to n bytes, and one Chinese is two bytes.
Occupied space:
nvarchar (n) is a character that takes up two bytes of space.
varchar (n) Chinese accounts for two bytes of space in English.
Value range of N:
The range of nvarchar (n) n is: between 1 and 4000
The range of varchar (n) n is: between 1 and 8000
Whether the size of n affects performance:
The length n in varchar and nvarchar does not affect space size and performance. Unless N is max and the content is greater than 4000 or 8000
Set N More is the business needs, such as restricting the ID card can only enter 18 digits, then more error, or prevent malicious attacks to support the hard drive. No impact on space or performance
n Set how much better:
Since there is no impact on space and performance, then we just consider business needs, I analyzed Microsoft's database, mostly set to: 256, also see 64,128,512,max, may be easy to remember it.
varchar (n), nvarchar (n) Storage space Example Explanation:
A variable-length Unicode character data that contains n characters. The storage size of bytes is twice times the number of characters entered.
Two fields have field values: me and coffee.
The varchar field accounts for 2x2+6=10 bytes of storage, while the nvarchar field accounts for 8x2=16 bytes of storage space.
If the field value is only English can choose varchar, and the field value has more double-byte (Chinese, Korean, etc.) characters when using nvarchar.
How do varchar and nvarchar choose?
varchar uses a single byte to store data in SQL Server, and nvarchar uses Unicode to store the data. Chinese characters stored in SQL Server are saved as two bytes (typically Unicode encoded), English characters are saved to the database, and if the field type is varchar, only one byte is consumed, and if the field is of type nvarchar, two bytes are used.
Under normal circumstances, we can also store Chinese characters using varchar, but if the operating system is an English operating system and the support is not comprehensive, the text character in SQL Server store is varchar is garbled (shown as??). And under normal circumstances, the host will support the Chinese environment, so if the use of varchar to store data, in the development phase is not found. In most cases, there will be no problem at the time of deployment.
But! If the host computer is an English operating system and does not support the Chinese environment, then the problem comes out. All varchar fields are garbled when they are stored in Chinese (shown as??). ）． And generally you don't know this because you're using the wrong data type to store the resulting, you'll try to install the Chinese font, try to set the operating system's language environment ... None of this solves the problem, and the only solution is to nvarchar (or nchar) the type of database field. More familiar with the project management of friends should know, to the deployment stage to modify the database is a very scary thing.
Another good thing about using nvarchar is that you don't need to consider the difference between the two characters when judging a string.
Of course, using nvarchar to store English characters will increase storage space by one more times. But given the low cost of storage, prioritizing compatibility gives you more benefits.
Therefore, when design should try to use nvarchar to store data. Use varchar to store only if you are sure that the field is not saved in Chinese.

If varchar (300) and varchar (8000) both store the same number of characters, there is no difference in performance and there is no difference in storage behavior. Because they all have the same storage structure, two-byte offsets, two-byte columns (if all the columns in the table are varchar types). The difference is only in storage capacity.
Most performance comparisons are focused on varchar and char,varchar and varchar (max). Also, out-of-line storage (supported by SQL Server 2005).

varchar (max) (LOB type) is different from the varchar storage method.
When the LOB data is sufficiently small, consider storing the data directly in the data row (the data page where the row resides), thereby avoiding additional read LOB pages and increasing the efficiency of accessing the LOB data (the threshold for storing LOB data directly on the data page is set by the text in row option).
When the LOB data is larger than this threshold, or if the row size exceeds 8060 bytes (single row maximum size), the LOB data is stored on the LOB page and a 16-byte pointer to the LOB page is retained in the data page. The efficiency of its access will of course be low.
In addition, a malicious user can use this to "explode" your disk.

This article refers to the content: http://www.yongfa365.com/Item/SQLServer-varchar-nvarchar.html

Relationships between char, varchar, varchar2, nvarchar in the database