Điều này thực sự sẽ phải được đo lường, chúng tôi có thể đưa ra một số "phỏng đoán" dựa trên những gì chúng tôi biết và những gì chúng tôi giả định, nhưng đó chỉ là những phỏng đoán.
Bạn không đề cập đến việc bảng này là InnoDB hay MyISAM với các hàng động hay MyISAM với các hàng có độ dài cố định. Điều đó sẽ tạo ra một số khác biệt.
Nhưng đối với các giá trị như giá trị bạn đã đăng, '961637593864109_412954765521130' (31 ký tự), giả sử bạn đang sử dụng một bộ ký tự byte đơn (ví dụ:latin1) hoặc một bộ ký tự mã hóa các ký tự cụ thể đó thành một byte đơn (ví dụ:utf8) ...
Đối với định dạng động InnoDB và MyISAM, đó là 31 + 1-8 =24 byte phụ cho hàng đó. (BIGINT vừa với 8 byte, giá trị VARCHAR (31) gồm 31 ký tự sẽ sử dụng 32 byte.)
Đối với bảng MyISAM có các hàng có độ dài cố định, đó sẽ là sự khác biệt là 23 byte cho mỗi hàng. (Không gian được dành cho tất cả 31 ký tự và độ dài không cần phải được lưu trữ.)
Giá trị khóa chính đó cũng sẽ được lặp lại trong mọi chỉ mục, do đó, cũng có không gian tăng lên với mỗi chỉ mục.
Giả sử rằng các hàng trong bảng của bạn là 120 byte bằng cách sử dụng BIGINT và các hàng là 144 byte với VARCHAR, đó là 20% tăng. Các hàng của bạn càng lớn, tỷ lệ phần trăm tăng càng nhỏ và ngược lại.
Đối với 1.000.000 hàng (tôi muốn nói "một hàng meelyun" giống như cách mà Tiến sĩ Evil đặt ngón út của mình lên khóe miệng và nói "một triệu đô la"), 24 byte trên mỗi hàng tổng cộng khoảng 24MB.
Nhưng nó không thực sự dễ dàng như vậy. Về không gian InnoDB, vấn đề là làm thế nào để các hàng có thể "vừa vặn" với một khối. Kích thước hàng trung bình càng lớn thì lượng không gian trống trong một khối càng lớn.
Nếu bạn không làm bất cứ điều gì với các hàng ngoại trừ lưu trữ chúng trên đĩa, thì đó thực sự chỉ là sự gia tăng dung lượng ổ đĩa, tăng thêm thời gian và không gian cho các bản sao lưu.
Nếu cùng một số hàng "144 byte" nằm trong một khối là hàng "120 byte", thì bạn sẽ không thấy bất kỳ sự khác biệt nào về không gian. Nhưng nếu ít hàng hơn vừa với một khối, thì đó là nhiều khối hơn, nhiều không gian hơn trong vùng đệm InnoDB, nhiều i / o hơn, v.v.
Đối với các truy vấn của một hàng, theo giá trị khóa chính hoặc bằng một số tra cứu chỉ mục duy nhất khác, sự khác biệt sẽ không đáng kể.
Nếu bạn đang xử lý các tập kết quả lớn hơn, thì đó là bộ nhớ bổ sung để chuẩn bị tập kết quả và các byte thừa để chuyển đến máy khách, v.v.
Nếu khóa VARCHAR được thiết kế theo cách mà "nhóm" các hàng được truy cập cùng nhau có cùng phần đầu của giá trị khóa, thì với InnoDB, thực sự có thể có một số cải thiện về hiệu suất. Đó là bởi vì khóa chính là khóa cụm ... cơ hội tốt hơn nhiều là các hàng cần thiết để đáp ứng truy vấn nằm trong cùng một khối, thay vì nằm rải rác trên một loạt các khối.
Điều ngược lại là nếu có các thao tác chèn và xóa được thực hiện, thì sẽ có nhiều không gian trống hơn trong một số khối. (Với việc xóa, không gian cho các hàng đã xóa vẫn còn trong khối; để sử dụng lại hàng đó, bạn cần phải chèn một hàng có cùng giá trị khóa (hoặc ít nhất một giá trị khóa đủ gần để hàng đó nằm trong cùng một khối .) Và với các lần chèn ngẫu nhiên, chúng ta sẽ nhận được các phần tách khối.
