FORMAT trả về kích thước hàng lớn và kích thước dữ liệu

Tôi ngạc nhiên với một trong những phát hiện của tôi rằng việc sử dụng một FORMAT ()ảnh hưởng rất lớn đến kích thước hàng và kích thước dữ liệu. Nó gần như gấp 250 lần kích thước của việc không áp dụng FORMAT ().

Câu hỏi của tôi là:
1) Tại sao việc sử dụng FORMAT()có tác động lớn đến kích thước như vậy? Đối với tôi, chỉ chênh lệch 1,23 so với 1,23 đô la, có lẽ là chênh lệch 1 ký tự. Và nó có vấn đề với kích thước khổng lồ như vậy?

2) Tại sao chúng ta vẫn được khuyến khích sử dụng FORMAT()trong máy chủ SQL thay vì sử dụng nối chuỗi như dưới đây. Vì bên dưới chỉ có kích thước dữ liệu 2X và sử dụng định dạng trả về kích thước dữ liệu 250x. HOẶC kích thước dữ liệu không phải là một phép đo quan trọng?

SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;

3) Có kích thước dữ liệu 464MB có nghĩa là tôi sẽ trả lại 464 MB dữ liệu cho khách hàng không?

================================================== ======

Dưới đây là những phát hiện của tôi với cơ sở dữ liệu AdventureWorks2012.

SELECT UnitPrice FROM Sales.SalesOrderDetail;

Số lượng hàng thực tế: 121317
Số lượng hàng
ước tính : 121317 Kích thước hàng ước tính: 15B
Kích thước dữ liệu ước tính: 1777KB

SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;

Số lượng hàng thực tế: 121317
Kích thước hàng ước tính: 26B
Kích thước dữ liệu ước tính: 3060KB

SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;

Số hàng thực tế: 121317
Kích thước hàng ước tính: 4011B
Kích thước dữ liệu ước tính: 464MB

FORMAT()có một đầu ra (không được ghi nhận) nvarchar(4000), ít nhất là trong các trường hợp chuyển đổi int và ngày thành chuỗi. Các tài liệu chỉ đơn giản nói ...

Độ dài của giá trị trả về được xác định bởi định dạng .

Nhưng sau đó không giải thích hoặc cung cấp bất kỳ ví dụ. Tuy nhiên, bạn có thể thấy những gì tôi đang mô tả với:

SELECT TOP (1) object_id, x = FORMAT(object_id, 'en-us') 
  INTO #blat FROM sys.all_objects;

EXEC tempdb.sys.sp_help N'#blat';

Kết quả là xlà một nvarcharvới chiều dài 8.000 (đây là số byte, không phải là số lượng ký tự).

Kích thước hàng ước tính dựa trên giả định rằng các giá trị độ rộng thay đổi sẽ được phân bổ một nửa. Vì vậy, nó mong đợi 2.000 ký tự (4.000 byte) trên mỗi hàng (ngay cả khi các tham số cụ thể bạn cung cấp không thể dẫn đến nhiều ký tự đó). Tôi chứng minh điều này (nhưng không FORMAT()cụ thể) trong một câu trả lời khác, việc sử dụng varchar (5000) có tệ so với varchar (255) không?

Đây là một lý do tôi thích sử dụng CONVERT()và TRY_CONVERT()tương đương thay vì FORMAT(), mặc dù đường cú pháp của nó. Ít nhất là với những người bạn có thể chuyển đổi thành một chiều rộng xác định thay vì dựa vào nó "được xác định bởi định dạng." Mà có thể hoặc có thể giúp kích thước ước tính, tùy thuộc vào truy vấn. Một ví dụ khác chứng minh lợi ích ở đây (mặc dù nó yêu cầu mã xấu hơn):

DECLARE @m float = 32.74532323;

SELECT 
    a = @m, 
    b = FORMAT(@m, 'c'), 
    c = '$' + CONVERT(varchar(12), CONVERT(decimal(8,2),@m))
 INTO #splunge 
 FROM sys.all_objects;

EXEC tempdb.sys.sp_help N'#splunge';

Các kết quả:

a    float
b    nvarchar(4000)
c    varchar(13)

Một lý do tôi thích sử dụng CONVERT()và TRY_CONVERT()là FORMAT()hút từ góc độ thực hiện (xem FORMAT () là tốt đẹp và tất cả, nhưng ... ).

Ngoài ra, vui lòng không bao giờ sử dụng các loại chiều rộng thay đổi như varchar mà không chỉ định chiều dài .