Nó có thể phụ thuộc vào phiên bản MySQL bạn đang sử dụng. Xem tại đây .
Trước MySQL 5.0.3, kiểu DECIMAL được lưu trữ dưới dạng chuỗi và thường sẽ chậm hơn. Tuy nhiên, vì MySQL 5.0.3 nên kiểu DECIMAL được lưu trữ ở định dạng nhị phân nên với kích thước DECIMAL của bạn ở trên, có thể không có khác biệt nhiều về hiệu suất.
Vấn đề hiệu suất chính sẽ là dung lượng bị chiếm dụng bởi các loại khác nhau (với DECIMAL chậm hơn). Với MySQL 5.0.3+, điều này dường như ít gặp vấn đề hơn, tuy nhiên nếu bạn thực hiện tính toán số trên các giá trị như một phần của truy vấn, có thể có một số khác biệt về hiệu suất. Điều này có thể đáng để thử nghiệm vì không có dấu hiệu nào trong tài liệu mà tôi có thể xem.
Chỉnh sửa: Liên quan đến int(10) unsigned
, tôi lấy giá trị này ở mệnh giá chỉ là một số nguyên 4 byte. Tuy nhiên, giá trị này có giá trị tối đa là 4294967295, điều này hoàn toàn không cung cấp cùng một dải số với DECIMAL(10,0) unsigned
.
Như @Unreason đã chỉ ra, bạn sẽ cần sử dụng bigint
để bao gồm đầy đủ các số có 10 chữ số, đẩy kích thước lên đến 8 byte.
Một sai lầm phổ biến là khi chỉ định kiểu cột số trong MySQL, mọi người thường nghĩ rằng số trong ngoặc có ảnh hưởng đến kích thước của số mà chúng có thể lưu trữ. Nó không. Phạm vi số hoàn toàn dựa trên loại cột và nó có dấu hay không dấu. Số trong ngoặc dành cho mục đích hiển thị kết quả và không ảnh hưởng đến các giá trị được lưu trữ trong cột. Nó cũng sẽ không ảnh hưởng đến việc hiển thị kết quả trừ khi bạn chỉ định ZEROFILL
cũng như tùy chọn trên cột.