NCHAR stores Unicode text using a fixed number of characters defined at declaration time (N). Every value occupies the full length, padded with trailing spaces if shorter than N. Because it is Unicode, each character typically uses two bytes (or more in UTF-16/UTF-32 implementations), guaranteeing support for multilingual data. Unlike NVARCHAR, which is variable-length, NCHAR always reserves the specified space, making it predictable in storage but potentially wasteful if data lengths vary widely.Key points:- Part of the SQL standard as the National character fixed-length type.- Ideal for columns where all values share the same length (country codes, ISO abbreviations).- Collation and comparison use the database’s national character set, often UTF-16.- Trailing spaces are considered semantically insignificant in comparisons in most systems.- Maximum length varies by dialect (e.g., SQL Server: 4,000, Oracle: 2,000, MySQL: 65,535 bytes total row size limit).- Requires more storage than CHAR when the database default character set is single-byte.- Cannot store strings longer than the declared length; excess data raises an error or is truncated, depending on SQL mode.
n
(INTEGER) - Number of Unicode characters to allocate (mandatory, dialect limits apply)CHAR, NVARCHAR, VARCHAR, NATIONAL CHARACTER, COLLATION, UNICODE
SQL-92 (National Character Types)
Choose NCHAR when every stored value has an identical length, like ISO country codes. NVARCHAR is a better choice for variable-length text because it only allocates the space actually used.
Most engines store NCHAR in UTF-16, allocating 2 bytes per character. Some use UTF-32 for supplementary characters, raising storage to 4 bytes per character.
No. The database stores and returns the full fixed length including spaces. Use TRIM or RTRIM functions to remove them if needed.
The statement fails with an error in strict modes, or the string is silently truncated depending on the database’s SQL mode and settings.