2011-10-05 35 views
9

Câu hỏi nhanh. Liệu nó quan trọng từ điểm lưu trữ dữ liệu nếu tôi sẽ sử dụng giới hạn lĩnh vực thập phân hoặc hệ thập lục phân (nói 16,32,64 thay vì 10,20,50)?Là varchar (128) tốt hơn so với varchar (100)

Tôi hỏi vì tôi tự hỏi liệu điều này có liên quan gì đến các cụm trên HDD không?

Cảm ơn!

+2

Đây có phải là câu hỏi cho một RDBMS cụ thể hoặc một RDBMS cụ thể không? –

+0

bạn có dự định lưu trữ dữ liệu thập phân trong trường varchar không? –

+0

ypercube: mysql, InnoDB Tudor: không, chỉ văn bản ... trừ khi văn bản là một số :) – RandomWhiteTrash

Trả lời

9

VARCHAR (128) tốt hơn VARCHAR (100) nếu bạn cần lưu trữ chuỗi dài hơn 100 byte.

Nếu không, có rất ít lựa chọn giữa chúng; bạn nên chọn cái phù hợp hơn với độ dài tối đa của dữ liệu bạn có thể cần lưu trữ. Bạn sẽ không thể đo lường sự khác biệt hiệu suất giữa chúng. Ngoài ra, DBMS có lẽ chỉ lưu trữ dữ liệu bạn gửi, vì vậy nếu chuỗi trung bình của bạn là 16 byte, nó sẽ chỉ sử dụng 16 (hoặc, nhiều khả năng, 17 - cho phép 1 byte để lưu trữ chiều dài) byte trên đĩa . Kích thước lớn hơn có thể ảnh hưởng đến việc tính toán số lượng hàng có thể phù hợp trên một trang - bất thường. Vì vậy, việc lựa chọn kích thước nhỏ nhất đủ thích hợp - không lãng phí, không muốn. Vì vậy, trong tóm lại, có sự khác biệt nhỏ quý giá giữa hai về hiệu suất hoặc sử dụng đĩa, và sắp xếp để ranh giới nhị phân thuận tiện không thực sự tạo sự khác biệt.

2

Có nhưng không đơn giản như vậy. Đôi khi 128 có thể tốt hơn 100 và đôi khi, đó là cách khác.

Vậy điều gì đang xảy ra? varchar chỉ phân bổ không gian nếu cần thiết vì vậy nếu bạn lưu trữ hello world trong một varchar(100), nó sẽ lấy chính xác cùng một lượng không gian như trong một varchar(128).

Câu hỏi đặt ra là: Nếu bạn điền vào các hàng, bạn sẽ đạt đến giới hạn "chặn"/ranh giới hay không?

Cơ sở dữ liệu lưu trữ dữ liệu của chúng theo khối. Chúng có kích thước cố định, ví dụ 512 (giá trị này có thể được cấu hình cho một số cơ sở dữ liệu). Câu hỏi đặt ra là: DB phải đọc bao nhiêu khối để tìm nạp từng hàng? Các hàng có khoảng vài khối sẽ cần thêm I/O, do đó, điều này sẽ làm chậm bạn xuống.

Nhưng một lần nữa: Điều này không phụ thuộc vào kích thước tối đa lý thuyết của cột nhưng trên a) số cột bạn có (mỗi cột cần một chút không gian ngay cả khi nó trống hoặc null), b) số lượng cột chiều rộng cố định bạn có (number/decimal, char) và cuối cùng c) số lượng dữ liệu bạn có trong cột biến.

3

Nếu đó là Chương trình C, tôi cũng dành chút thời gian để suy nghĩ về điều đó. Nhưng với một cơ sở dữ liệu tôi để nó cho động cơ DB.

Người lập trình DB dành nhiều thời gian để suy nghĩ về bố trí bộ nhớ tốt nhất, vì vậy chỉ cần nói cho cơ sở dữ liệu những gì bạn cần và nó sẽ lưu trữ dữ liệu theo cách phù hợp nhất với công cụ DB (thường).

Nếu bạn muốn căn chỉnh dữ liệu, bạn sẽ cần chính xác kiến ​​thức về tổ chức dữ liệu nội bộ: Chuỗi được lưu trữ như thế nào? Một, hai hoặc 4 byte để lưu trữ độ dài? Nó có được lưu trữ dưới dạng chuỗi byte đơn thuần hoặc được mã hóa bằng UTF-8 UTF-16 UTF-32 không? Liệu DB cần byte thêm để xác định giá trị NULL hoặc> MAXINT? Có thể chuỗi được lưu trữ như là một chuỗi byte được kết thúc bằng NUL - sau đó cần thêm một byte trong nội bộ.

Cũng với VARCHAR nó không phải là cần thiết đúng, rằng DB sẽ luôn phân bổ 100 (128) byte cho chuỗi của bạn. Có lẽ nó lưu trữ chỉ là một con trỏ đến nơi mà không gian cho dữ liệu thực tế là.

Vì vậy, tôi khuyên bạn nên sử dụng VARCHAR (100) nếu đó là yêu cầu của bạn. Nếu DB quyết định sắp xếp nó bằng cách nào đó có chỗ cho thêm dữ liệu nội bộ, quá.

Cách khác: Giả sử bạn sử dụng VARCHAR (128) và mọi thứ kết hợp với nhau: DB phân bổ 128 byte cho dữ liệu của bạn. Ngoài ra nó cần thêm 2 byte để lưu trữ độ dài chuỗi thực tế - tạo ra 130 byte - và sau đó có thể là DB sắp xếp dữ liệu đến ranh giới tiếp theo (giả sử 32 byte): Dữ liệu thực tế cần thiết trên đĩa bây giờ là 160 byte 8-}

Các vấn đề liên quan