Bài đăng này có “chuỗi đính kèm:vì một lý do chính đáng. Chúng ta sẽ khám phá sâu về SQL VARCHAR, kiểu dữ liệu xử lý các chuỗi.
Ngoài ra, đây là "chỉ dành cho mắt của bạn" bởi vì không có chuỗi, sẽ không có bài đăng blog, trang web, hướng dẫn trò chơi, công thức được đánh dấu trang và nhiều hơn nữa để chúng ta có thể đọc và thưởng thức. Chúng tôi xử lý một chuỗi gazillion mỗi ngày. Vì vậy, với tư cách là nhà phát triển, bạn và tôi có trách nhiệm làm cho loại dữ liệu này được lưu trữ và truy cập hiệu quả.
Với suy nghĩ này, chúng tôi sẽ đề cập đến những gì quan trọng nhất đối với việc lưu trữ và hiệu suất. Nhập những việc nên làm và không nên cho loại dữ liệu này.
Nhưng trước đó, VARCHAR chỉ là một trong những kiểu chuỗi trong SQL. Điều gì làm cho nó khác biệt?
VARCHAR trong SQL là gì? (Có ví dụ)
VARCHAR là kiểu dữ liệu chuỗi hoặc ký tự có kích thước khác nhau. Bạn có thể lưu trữ các chữ cái, số và ký hiệu với nó. Bắt đầu với SQL Server 2019, bạn có thể sử dụng đầy đủ các ký tự Unicode khi sử dụng đối chiếu với hỗ trợ UTF-8.
Bạn có thể khai báo các cột hoặc biến VARCHAR bằng cách sử dụng VARCHAR [(n)], trong đó n là viết tắt của kích thước chuỗi tính bằng byte. Phạm vi giá trị của n là 1 đến 8000. Đó là rất nhiều dữ liệu ký tự. Nhưng thậm chí nhiều hơn, bạn có thể khai báo nó bằng cách sử dụng VARCHAR (MAX) nếu bạn cần một chuỗi khổng lồ lên đến 2GB. Điều đó đủ lớn cho danh sách bí mật và nội dung riêng tư trong nhật ký của bạn! Tuy nhiên, lưu ý rằng bạn cũng có thể khai báo nó mà không có kích thước và nó được đặt mặc định là 1 nếu bạn làm như vậy.
Hãy lấy một ví dụ.
DECLARE @actor VARCHAR(20) = 'Robert Downey Jr.';
DECLARE @movieCharacter VARCHAR(10) = 'Iron Man';
DECLARE @movie VARCHAR = 'Avengers';
SELECT @actor, @movieCharacter, @movie
Trong Hình 1, 2 cột đầu tiên có kích thước được xác định. Cột thứ ba được để lại mà không có kích thước. Vì vậy, từ “Avengers” bị cắt ngắn vì VARCHAR không có kích thước được khai báo sẽ mặc định là 1 ký tự.
Bây giờ, chúng ta hãy thử một cái gì đó rất lớn. Nhưng lưu ý rằng truy vấn này sẽ mất một lúc để chạy - 23 giây trên máy tính xách tay của tôi.
-- This will take a while
DECLARE @giganticString VARCHAR(MAX);
SET @giganticString = REPLICATE(CAST('kage bunshin no jutsu' AS VARCHAR(MAX)),100000000)
SELECT DATALENGTH(@giganticString)
Để tạo ra một chuỗi lớn, chúng tôi đã sao chép kage bunshin no jutsu 100 triệu lần. Lưu ý CAST trong REPLICATE. Nếu bạn KHÔNG ĐÚC biểu thức chuỗi thành VARCHAR (MAX), kết quả sẽ chỉ bị cắt bớt tối đa 8000 ký tự.
Nhưng SQL VARCHAR so với các kiểu dữ liệu chuỗi khác như thế nào?
Sự khác biệt giữa CHAR và VARCHAR trong SQL
So với VARCHAR, CHAR là kiểu dữ liệu ký tự có độ dài cố định. Bất kể giá trị nhỏ hay lớn mà bạn đặt cho biến CHAR, kích thước cuối cùng là kích thước của biến. Kiểm tra các so sánh bên dưới.
DECLARE @tvSeriesTitle1 VARCHAR(20) = 'The Mandalorian';
DECLARE @tvSeriesTitle2 CHAR(20) = 'The Mandalorian';
SELECT DATALENGTH(@tvSeriesTitle1) AS VarcharValue,
DATALENGTH(@tvSeriesTitle2) AS CharValue
Kích thước của chuỗi "The Mandalorian" là 15 ký tự. Vì vậy, VarcharValue cột phản ánh chính xác nó. Tuy nhiên, CharValue vẫn giữ nguyên kích thước 20 - nó có 5 khoảng trống ở bên phải.
SQL VARCHAR so với NVARCHAR
Hai điều cơ bản cần lưu ý khi so sánh các loại dữ liệu này.
Đầu tiên, nó là kích thước tính bằng byte. Mỗi ký tự trong NVARCHAR có kích thước gấp đôi VARCHAR. NVARCHAR (n) chỉ từ 1 đến 4000.
Sau đó, các ký tự mà nó có thể lưu trữ. NVARCHAR có thể lưu trữ các ký tự đa ngôn ngữ như tiếng Hàn, tiếng Nhật, tiếng Ả Rập, v.v. Nếu bạn định lưu trữ lời bài hát K-Pop Hàn Quốc trong cơ sở dữ liệu của mình, thì loại dữ liệu này là một trong những lựa chọn của bạn.
Hãy xem một ví dụ. Chúng tôi sẽ sử dụng nhóm K-pop 세븐틴 hoặc Seventeen bằng tiếng Anh.
DECLARE @kpopGroupKorean NVARCHAR(5) = N'세븐틴';
SELECT @kpopGroupKorean AS KPopGroup,
DATALENGTH(@kpopGroupKorean) AS SizeInBytes,
LEN(@kpopGroupKorean) AS [NoOfChars]
Đoạn mã trên sẽ xuất ra giá trị chuỗi, kích thước của nó tính bằng byte và số ký tự. Nếu đây là các ký tự không phải Unicode, số lượng ký tự bằng kích thước tính bằng byte. Nhưng đây không phải là trường hợp. Xem Hình 4 bên dưới.
Xem? Nếu NVARCHAR có 3 ký tự, kích thước tính bằng byte gấp đôi. Nhưng với VARCHAR thì không. Điều này cũng đúng nếu bạn sử dụng các ký tự tiếng Anh.
Nhưng làm thế nào về NCHAR? NCHAR là bản sao của CHAR cho các ký tự Unicode.
SQL Server VARCHAR với Hỗ trợ UTF-8
VARCHAR với hỗ trợ UTF-8 có thể thực hiện được ở cấp máy chủ, cấp cơ sở dữ liệu hoặc cấp cột bảng bằng cách thay đổi thông tin đối chiếu. Đối chiếu để sử dụng phải hỗ trợ UTF-8.
THU NHẬP MÁY CHỦ SQL
Hình 5 giới thiệu cửa sổ trong SQL Server Management Studio hiển thị sự đối chiếu của máy chủ.
THU THẬP CƠ SỞ DỮ LIỆU
Trong khi đó, Hình 6 cho thấy sự đối chiếu của AdventureWorks cơ sở dữ liệu.
LẠNH CỘT BẢNG
Cả máy chủ và cơ sở dữ liệu đối chiếu ở trên cho thấy rằng UTF-8 không được hỗ trợ. Chuỗi đối chiếu phải có _UTF8 trong đó để hỗ trợ UTF-8. Nhưng bạn vẫn có thể sử dụng hỗ trợ UTF-8 ở cấp cột của bảng. Xem ví dụ.
CREATE TABLE SeventeenMemberList
(
id INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
KoreanName VARCHAR(20) COLLATE Latin1_General_100_BIN2_UTF8 NOT NULL,
EnglishName VARCHAR(20) NOT NULL
)
Mã trên có Latin1_General_100_BIN2_UTF8 đối chiếu cho KoreanName cột. Mặc dù VARCHAR chứ không phải NVARCHAR, cột này sẽ chấp nhận các ký tự tiếng Hàn. Hãy chèn một số bản ghi và sau đó xem chúng.
INSERT INTO SeventeenMemberList
(KoreanName, EnglishName)
VALUES
(N'에스쿱스','S.Coups')
,(N'원우','Wonwoo')
,(N'민규','Mingyu')
,(N'버논','Vernon')
,(N'우지','Woozi')
,(N'정한','Jeonghan')
,(N'조슈아','Joshua')
,(N'도겸','DK')
,(N'승관','Seungkwan')
,(N'호시','Hoshi')
,(N'준','Jun')
,(N'디에잇','The8')
,(N'디노','Dino')
SELECT * FROM SeventeenMemberList
ORDER BY KoreanName
COLLATE Latin1_General_100_BIN2_UTF8
Chúng tôi đang sử dụng tên của nhóm nhạc K-pop Seventeen bằng tiếng Hàn và tiếng Anh. Đối với các ký tự tiếng Hàn, hãy lưu ý rằng bạn vẫn phải đặt tiền tố giá trị bằng N , giống như những gì bạn làm với các giá trị NVARCHAR.
Sau đó, khi sử dụng SELECT với ORDER BY, bạn cũng có thể sử dụng đối chiếu. Bạn có thể quan sát điều này trong ví dụ trên. Điều này sẽ tuân theo các quy tắc sắp xếp cho đối chiếu được chỉ định.
LƯU TRỮ VARCHAR VỚI HỖ TRỢ UTF-8
Nhưng việc lưu trữ những ký tự này như thế nào? Nếu bạn mong đợi 2 byte cho mỗi ký tự thì bạn sẽ rất ngạc nhiên. Xem Hình 8.
Vì vậy, nếu bộ nhớ quan trọng đối với bạn, hãy xem xét bảng bên dưới khi sử dụng VARCHAR với hỗ trợ UTF-8.
| Characters | Kích thước tính bằng byte |
| Ascii 0 - 127 | 1 |
| Chữ viết dựa trên tiếng Latinh và tiếng Hy Lạp, Cyrillic, Coptic, Armenia, Hebrew, Arabic, Syriac, Tāna và N’Ko | 2 |
| Chữ viết Đông Á như tiếng Trung, tiếng Hàn và tiếng Nhật | 3 |
| Các ký tự trong phạm vi 010000–10FFFF | 4 |
Ví dụ tiếng Hàn của chúng tôi là chữ viết Đông Á, vì vậy nó có 3 byte cho mỗi ký tự.
Bây giờ chúng ta đã hoàn tất việc mô tả và so sánh VARCHAR với các loại chuỗi khác, bây giờ chúng ta hãy đề cập đến việc Nên và Không nên
Việc cần làm là Sử dụng VARCHAR trong SQL Server
1. Chỉ định kích thước
Điều gì có thể xảy ra nếu không chỉ định kích thước?
TRUNCATION STRING
Nếu bạn lười chỉ định kích thước, thì việc cắt ngắn chuỗi sẽ xảy ra. Bạn đã thấy một ví dụ về điều này trước đó.
TÁC ĐỘNG LƯU TRỮ VÀ HIỆU SUẤT
Một xem xét khác là lưu trữ và hiệu suất. Bạn chỉ cần đặt kích thước phù hợp cho dữ liệu của mình, không cần nhiều hơn. Nhưng làm thế nào bạn có thể biết? Để tránh bị cắt bớt trong tương lai, bạn có thể chỉ cần đặt nó ở kích thước lớn nhất. Đó là VARCHAR (8000) hoặc thậm chí VARCHAR (MAX). Và 2 byte sẽ được lưu trữ nguyên trạng. Điều tương tự với 2GB. Nó có quan trọng không?
Trả lời câu hỏi đó sẽ đưa chúng ta đến khái niệm về cách SQL Server lưu trữ dữ liệu. Tôi có một bài viết khác giải thích chi tiết điều này với các ví dụ và hình ảnh minh họa.
Nói tóm lại, dữ liệu được lưu trữ trong các trang 8KB. Khi một hàng dữ liệu vượt quá kích thước này, SQL Server sẽ di chuyển hàng đó sang một đơn vị phân bổ trang khác có tên ROW_OVERFLOW_DATA.
Giả sử bạn có dữ liệu VARCHAR 2 byte có thể vừa với đơn vị phân bổ trang gốc. Khi bạn lưu trữ một chuỗi lớn hơn 8000 byte, dữ liệu sẽ được chuyển đến trang tràn hàng. Sau đó, lại thu nhỏ nó xuống kích thước thấp hơn và nó sẽ được chuyển trở lại trang ban đầu. Việc di chuyển tới lui gây ra nhiều I / O và tắc nghẽn hiệu suất. Việc lấy dữ liệu này từ 2 trang thay vì 1 trang cũng cần thêm I / O.
Một lý do khác là lập chỉ mục. VARCHAR (MAX) là một KHÔNG lớn như một khóa chỉ mục. Trong khi đó, VARCHAR (8000) sẽ vượt quá kích thước khóa chỉ mục tối đa. Đó là 1700 byte cho các chỉ mục không phân cụm và 900 byte cho các chỉ mục được phân nhóm.
TÁC ĐỘNG CỦA CHUYỂN ĐỔI DỮ LIỆU
Tuy nhiên, có một cân nhắc khác:chuyển đổi dữ liệu. Hãy thử nó với một CAST không có kích thước như mã bên dưới.
SELECT
SYSDATETIMEOFFSET() AS DateTimeInput
,CAST(SYSDATETIMEOFFSET() AS VARCHAR) AS ConvertedDateTime
,DATALENGTH(CAST(SYSDATETIMEOFFSET() AS VARCHAR)) AS ConvertedLength
Mã này sẽ thực hiện chuyển đổi ngày / giờ với thông tin múi giờ thành VARCHAR.
Vì vậy, nếu chúng tôi lười xác định kích thước trong khi CAST hoặc CONVERT, kết quả chỉ giới hạn trong 30 ký tự.
Làm thế nào về việc chuyển đổi NVARCHAR thành VARCHAR với hỗ trợ UTF-8? Có một lời giải thích chi tiết về điều này sau, vì vậy hãy tiếp tục đọc.
2. Sử dụng VARCHAR nếu kích thước chuỗi thay đổi đáng kể
Tên từ AdventureWorks cơ sở dữ liệu khác nhau về kích thước. Một trong những cái tên ngắn nhất là Min Su, trong khi cái tên dài nhất là Osarumwense Uwaifiokun Agbonile. Đó là từ 6 đến 31 ký tự bao gồm cả dấu cách. Hãy nhập những tên này vào 2 bảng và so sánh giữa VARCHAR và CHAR.
-- Table using VARCHAR
CREATE TABLE VarcharAsIndexKey
(
id INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
varcharName VARCHAR(50) NOT NULL
)
GO
CREATE INDEX IX_VarcharAsIndexKey_varcharName ON VarcharAsIndexKey(varcharName)
GO
-- Table using CHAR
CREATE TABLE CharAsIndexKey
(
id INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
charName CHAR(50) NOT NULL
)
GO
CREATE INDEX IX_CharAsIndexKey_charName ON CharAsIndexKey(charName)
GO
INSERT INTO VarcharAsIndexKey (varcharName)
SELECT DISTINCT
LastName + ', ' + FirstName + ' ' + ISNULL(MiddleName,'')
FROM AdventureWorks.Person.Person
INSERT INTO CharAsIndexKey (charName)
SELECT DISTINCT
LastName + ', ' + FirstName + ' ' + ISNULL(MiddleName,'')
FROM AdventureWorks.Person.Person
GO
Cái nào trong số 2 cái nào tốt hơn? Hãy kiểm tra các lần đọc logic bằng cách sử dụng mã bên dưới và kiểm tra đầu ra của IO THỐNG KÊ.
SET NOCOUNT ON
SET STATISTICS IO ON
SELECT id, varcharName
FROM VarcharAsIndexKey
SELECT id, charName
FROM CharAsIndexKey
SET STATISTICS IO OFF
Bài đọc logic:
Càng ít logic càng tốt. Ở đây, cột CHAR đã sử dụng nhiều hơn gấp đôi so với VARCHAR. Do đó, VARCHAR thắng trong ví dụ này.
3. Sử dụng VARCHAR làm Khóa chỉ mục thay vì CHAR khi giá trị thay đổi theo kích thước
Điều gì đã xảy ra khi được sử dụng làm khóa chỉ mục? CHAR có giá vé tốt hơn VARCHAR không? Hãy sử dụng cùng một dữ liệu từ phần trước và trả lời câu hỏi này.
Chúng tôi sẽ truy vấn một số dữ liệu và kiểm tra các lần đọc logic. Trong ví dụ này, bộ lọc sử dụng khóa chỉ mục.
SET NOCOUNT ON
SET STATISTICS IO ON
SELECT varcharName FROM VarcharAsIndexKey
WHERE varcharName = 'Sai, Adriana A'
OR varcharName = 'Rogers, Caitlin D'
SELECT charName FROM CharAsIndexKey
WHERE charName = 'Sai, Adriana A'
OR charName = 'Rogers, Caitlin D'
SET STATISTICS IO OFF
Bài đọc logic:
Do đó, các khóa chỉ mục VARCHAR tốt hơn các khóa chỉ mục CHAR khi khóa có kích thước khác nhau. Nhưng còn CHÈN và CẬP NHẬT sẽ thay đổi các mục nhập chỉ mục thì sao?
KHI SỬ DỤNG CHÈN VÀ CẬP NHẬT
Hãy kiểm tra 2 trường hợp và sau đó kiểm tra các lần đọc logic như chúng ta thường làm.
SET STATISTICS IO ON
INSERT INTO VarcharAsIndexKey (varcharName)
VALUES ('Ruffalo, Mark'), ('Johansson, Scarlett')
INSERT INTO CharAsIndexKey (charName)
VALUES ('Ruffalo, Mark'), ('Johansson, Scarlett')
SET STATISTICS IO OFF
Bài đọc logic:
VARCHAR vẫn tốt hơn khi chèn các bản ghi. Làm thế nào về CẬP NHẬT?
SET STATISTICS IO ON
UPDATE VarcharAsIndexKey
SET varcharName = 'Hulk'
WHERE varcharName = 'Ruffalo, Mark'
UPDATE CharAsIndexKey
SET charName = 'Hulk'
WHERE charName = 'Ruffalo, Mark'
SET STATISTICS IO OFF
Bài đọc logic:
Có vẻ như VARCHAR lại thắng.
Cuối cùng, nó thắng cuộc thử nghiệm của chúng tôi, mặc dù nó có thể là nhỏ. Bạn có trường hợp thử nghiệm lớn hơn chứng minh điều ngược lại không?
4. Xem xét VARCHAR với Hỗ trợ UTF-8 cho dữ liệu đa ngôn ngữ (SQL Server 2019+)
Nếu có sự kết hợp giữa các ký tự Unicode và không phải Unicode trong bảng của bạn, bạn có thể xem xét VARCHAR với hỗ trợ UTF-8 qua NVARCHAR. Nếu hầu hết các ký tự nằm trong phạm vi ASCII 0 đến 127, nó có thể tiết kiệm dung lượng so với NVARCHAR.
Để xem ý tôi là gì, hãy cùng so sánh.
NVARCHAR ĐỂ BIẾN ĐỔI VỚI HỖ TRỢ UTF-8
Bạn đã di chuyển cơ sở dữ liệu của mình sang SQL Server 2019 chưa? Bạn có dự định di chuyển dữ liệu chuỗi của mình sang đối chiếu UTF-8 không? Chúng tôi sẽ có một ví dụ về giá trị hỗn hợp của các ký tự tiếng Nhật và không phải tiếng Nhật để cung cấp cho bạn ý tưởng.
CREATE TABLE NVarcharToVarcharUTF8
(
NVarcharValue NVARCHAR(20) NOT NULL,
VarcharUTF8 VARCHAR(45) COLLATE Latin1_General_100_BIN2_UTF8 NOT NULL
)
GO
INSERT INTO NVarcharToVarcharUTF8
(NVarcharValue, VarcharUTF8)
VALUES
(N'NARUTO-ナルト- 疾風伝',N'NARUTO-ナルト- 疾風伝'); -- NARUTO Shippûden
SELECT
NVarcharValue
,LEN(NVarcharValue) AS nvarcharNoOfChars
,DATALENGTH(NVarcharValue) AS nvarcharSizeInBytes
,VarcharUTF8
,LEN(VarcharUTF8) AS varcharNoOfChars
,DATALENGTH(VarcharUTF8) AS varcharSizeInBytes
FROM NVarcharToVarcharUTF8
Bây giờ, dữ liệu đã được thiết lập, chúng tôi sẽ kiểm tra kích thước tính bằng byte của 2 giá trị:
Bất ngờ! Với NVARCHAR, kích thước là 30 byte. Đó là gấp 15 lần 2 ký tự. Nhưng khi chuyển đổi thành VARCHAR với hỗ trợ UTF-8, kích thước chỉ là 27 byte. Tại sao lại là 27? Kiểm tra cách tính toán điều này.
Do đó, 9 trong số các ký tự là 1 byte mỗi ký tự. Điều đó thật thú vị vì với NVARCHAR, các chữ cái tiếng Anh cũng có kích thước 2 byte. Phần còn lại của các ký tự tiếng Nhật mỗi ký tự là 3 byte.
Nếu đây là tất cả các ký tự tiếng Nhật, chuỗi 15 ký tự sẽ là 45 byte và cũng sử dụng kích thước tối đa của VarcharUTF8 cột. Lưu ý rằng kích thước của NVarcharValue cột nhỏ hơn VarcharUTF8 .
Kích thước không thể bằng nhau khi chuyển đổi từ NVARCHAR hoặc dữ liệu có thể không vừa. Bạn có thể tham khảo Bảng 1.
Xem xét tác động đến kích thước khi chuyển đổi NVARCHAR thành VARCHAR với hỗ trợ UTF-8.
Những điều không nên khi Sử dụng VARCHAR trong SQL Server
1. Khi Kích thước chuỗi được cố định và không thể vô hiệu, hãy sử dụng CHAR để thay thế.
Nguyên tắc chung khi yêu cầu một chuỗi có kích thước cố định là sử dụng CHAR. Tôi làm theo điều này khi tôi có yêu cầu dữ liệu cần khoảng trống được đệm bên phải. Nếu không, tôi sẽ sử dụng VARCHAR. Tôi gặp một số trường hợp sử dụng khi tôi cần kết xuất các chuỗi có độ dài cố định không có dấu phân cách vào tệp văn bản cho ứng dụng khách.
Hơn nữa, tôi chỉ sử dụng cột CHAR nếu các cột này không thể null. Tại sao? Bởi vì kích thước tính bằng byte của cột CHAR khi NULL bằng kích thước xác định của cột. Tuy nhiên, VARCHAR khi NULL có kích thước là 1 cho dù kích thước được xác định là bao nhiêu. Chạy mã bên dưới và tự mình xem.
DECLARE @charValue CHAR(50) = NULL;
DECLARE @varcharValue VARCHAR(1000) = NULL;
SELECT
DATALENGTH(ISNULL(@charvalue,0)) AS CharSize
,DATALENGTH(ISNULL(@varcharvalue,0)) AS VarcharSize
2. Không sử dụng VARCHAR (n) Nếu n Sẽ Vượt quá 8000 Byte. Sử dụng VARCHAR (MAX) để thay thế.
Bạn có một chuỗi sẽ vượt quá 8000 byte không? Đây là lúc sử dụng VARCHAR (MAX). Nhưng đối với các dạng dữ liệu phổ biến nhất như tên và địa chỉ, VARCHAR (MAX) quá mức cần thiết và sẽ ảnh hưởng đến hiệu suất. Theo kinh nghiệm cá nhân của tôi, tôi không nhớ yêu cầu rằng tôi đã sử dụng VARCHAR (MAX).
3. Khi sử dụng các ký tự đa ngôn ngữ với SQL Server 2017 trở xuống. Sử dụng NVARCHAR để thay thế.
Đây là một lựa chọn hiển nhiên nếu bạn vẫn sử dụng SQL Server 2017 trở xuống.
Tóm tắt
Kiểu dữ liệu VARCHAR đã phục vụ chúng tôi rất tốt cho rất nhiều khía cạnh. Nó đã làm cho tôi kể từ SQL Server 7. Tuy nhiên, đôi khi, chúng tôi vẫn đưa ra những lựa chọn sai lầm. Trong bài đăng này, SQL VARCHAR được định nghĩa và so sánh với các kiểu dữ liệu chuỗi khác với các ví dụ. Và một lần nữa, đây là những việc nên làm và không nên để có cơ sở dữ liệu nhanh hơn:
Nên làm:
- Chỉ định kích thước n trong VARCHAR [(n)] ngay cả khi nó là tùy chọn.
- Sử dụng nó khi kích thước chuỗi thay đổi đáng kể.
- Coi các cột VARCHAR là khóa chỉ mục thay vì CHAR.
- Và nếu bạn hiện đang sử dụng SQL Server 2019, hãy xem xét VARCHAR cho các chuỗi đa ngôn ngữ có hỗ trợ UTF-8.
Không nên:
- Không sử dụng VARCHAR khi kích thước chuỗi là cố định và không thể rỗng.
- Không sử dụng VARCHAR (n) khi kích thước chuỗi vượt quá 8000 byte.
- Và không sử dụng VARCHAR cho dữ liệu đa ngôn ngữ khi sử dụng SQL Server 2017 trở về trước.
Bạn có bổ sung thêm gì không? Cho chúng tôi biết trong phần ý kiến. Nếu bạn nghĩ điều này sẽ giúp ích cho bạn bè là nhà phát triển của mình, thì hãy chia sẻ điều này trên các nền tảng mạng xã hội yêu thích của bạn.
