Số lượng bản ghi tối đa trong bảng cơ sở dữ liệu MySQL

174

Giới hạn trên của các bản ghi cho bảng cơ sở dữ liệu MySQL là gì. Tôi đang tự hỏi về lĩnh vực tự động. Điều gì sẽ xảy ra nếu tôi thêm hàng triệu hồ sơ? Làm thế nào để xử lý loại tình huống này? Cám ơn!

— xpepermint
nguồn

16

Chưa kể 1.21 TUYỆT VỜI!

— Ben

2

Ít nhất là nếu bộ nhớ phục vụ, giới hạn được đặt bởi công cụ lưu trữ, vì vậy (ví dụ) khi sử dụng MyISAM, bạn sẽ nhận được một giới hạn khác với việc sử dụng InnoDB.

— Jerry Coffin

77

@ Onion-Knight: Tôi không đồng ý. Việc chèn hàng triệu hàng vào một bảng là bình thường và một số cơ sở dữ liệu có giới hạn, vì vậy rất đáng để hỏi. Nếu người ta hỏi liệu MySQL có hỗ trợ hàng triệu bảng không thì đó có thể là dấu hiệu của một lỗi kiến trúc.

— Bill Karwin

61

Các kiểu int mysql có thể thực hiện khá nhiều hàng: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

unsigned intgiá trị lớn nhất là 4,294,967,295
unsigned bigintgiá trị lớn nhất là18,446,744,073,709,551,615

— KM.
nguồn

8

Tối đa 2147483647, vì vậy bạn chỉ phải tạo ra sự tự động lớn nếu bạn đang làm việc với nhiều tỷ mục? (điều này có thể sẽ khiến các tuyên bố lựa chọn của bạn tan chảy từ lâu trước đó)

— Kzqai

2

@Tchalvak đó là để ký int, vui lòng đọc tài liệu mysql.

— Leandro

8

Bối cảnh của câu hỏi là về trường tăng tự động có thể xử lý nhiều hàng không và không giới hạn các tài nguyên khác

— KM.

21

Người đăng không hỏi về số hoặc bất kỳ loại dữ liệu nào khác. . Tôi thực sự không hiểu làm thế nào điều này có thể được gắn cờ là một câu trả lời chính xác. Mặc dù tôi phải thừa nhận rằng câu hỏi không rõ ràng, chúng ta nên phân biệt giữa kiểu dữ liệu PK và số lượng hàng tối đa cho một bảng.

— Bery

1

@Bery, OP đã phân biệt những gì họ đã có sau khi chọn đây là câu trả lời của họ. Rõ ràng họ quan tâm đến khả năng của trường tăng tự động, mà câu trả lời của tôi bao gồm, và không phải là những hạn chế của các tài nguyên khác.

— KM.

238

Giá trị lớn nhất của một số nguyên ít liên quan đến số lượng hàng tối đa bạn có thể lưu trữ trong một bảng.

Đúng là nếu bạn sử dụng int hoặc bigint làm khóa chính, bạn chỉ có thể có nhiều hàng bằng số giá trị duy nhất trong kiểu dữ liệu của khóa chính, nhưng bạn không phải biến khóa chính của mình thành số nguyên , bạn có thể biến nó thành CHAR (100). Bạn cũng có thể khai báo khóa chính trên nhiều cột.

Có các ràng buộc khác về kích thước bảng bên cạnh số lượng hàng. Chẳng hạn, bạn có thể sử dụng một hệ điều hành có giới hạn kích thước tệp. Hoặc bạn có thể có một ổ cứng 300 GB chỉ có thể lưu trữ 300 triệu hàng nếu mỗi hàng có kích thước 1KB.

Giới hạn của kích thước cơ sở dữ liệu là rất cao:

http://dev.mysql.com/doc/refman/5.1/en/source-configuration-options.html

Công cụ lưu trữ MyISAM hỗ trợ 2 ³² hàng mỗi bảng, nhưng bạn có thể xây dựng MySQL với --with-big-tablestùy chọn để hỗ trợ tối đa 2 ⁶⁴ hàng mỗi bảng.

http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html

Công cụ lưu trữ InnoDB dường như không có giới hạn về số lượng hàng, nhưng nó có giới hạn về kích thước bảng là 64 terabyte. Có bao nhiêu hàng phù hợp với điều này phụ thuộc vào kích thước của mỗi hàng.

— Bill Karwin
nguồn

62

tào lao - tôi ước tôi đã đọc được điều này trước đây ... tôi đã vượt qua kích thước 64 terrabyte của mình trên một trong những bàn của tôi và bây giờ hệ thống của tôi rất chậm!

— JM4

2 ^ 32 = 4.294.967.295 và 2 ^ 64 = 18.446.744.073.709.551.615 vì vậy ... Giá trị nguyên lớn nhất có một chút liên quan đến số lượng hàng tối đa. Không nhất thiết là khóa chính.

— teynon

1

@Tom, InnoDB là công cụ lưu trữ mặc định trong MySQL 5.5 và là lựa chọn tốt hơn trong 99% trường hợp.

— Bill Karwin

2

@ Ext3h, Sphinx Search thường là lựa chọn tốt hơn so với chỉ mục fulltext trong MyISAM hoặc InnoDB.

— Bill Karwin

1

Đối với mysql 8, giới hạn là 256 TB với kích thước trang là 64 KB.

— Vô dụngCat

13

Tôi đề nghị, không bao giờ xóa dữ liệu. Đừng nói nếu các bảng dài hơn 1000 cắt ngắn cuối bảng. Cần phải có logic kinh doanh thực sự trong kế hoạch của bạn như người dùng này đã không hoạt động được bao lâu. Ví dụ, nếu nó dài hơn 1 năm thì đặt chúng vào một bảng khác. Bạn sẽ có điều này xảy ra hàng tuần hoặc hàng tháng trong một kịch bản bảo trì vào giữa thời gian chậm.

Khi bạn chạy vào nhiều hàng trong bảng thì bạn nên bắt đầu bảo vệ các bảng hoặc phân vùng và đưa dữ liệu cũ vào các bảng cũ theo năm như users_2011_jan, users_2011_feb hoặc sử dụng số cho tháng. Sau đó thay đổi chương trình của bạn để làm việc với mô hình này. Có thể tạo một bảng mới với ít thông tin hơn để tóm tắt dữ liệu trong ít cột hơn và sau đó chỉ tham khảo các bảng được phân vùng lớn hơn khi bạn cần thêm thông tin như khi người dùng đang xem hồ sơ của họ. Tất cả điều này nên được xem xét rất cẩn thận để trong tương lai nó không quá đắt để tái lập yếu tố. Bạn cũng có thể chỉ đặt những người dùng đến trang web của bạn mọi lúc trong một bảng và những người dùng không bao giờ đến trong một tập hợp các bảng được lưu trữ.

— PHPGuru
nguồn

1

Về vấn đề này, rất hữu ích khi xem phân vùng MySQL: dev.mysql.com/doc/refman/5.6/en/partitioning.html

— Wim Deblauwe

10

Trong InnoDB, với giới hạn về kích thước bảng là 64 terabyte và giới hạn kích thước hàng của MySQL là 65.535, có thể có 1.073.741.824 hàng. Đó sẽ là số lượng bản ghi tối thiểu sử dụng giới hạn kích thước hàng tối đa. Tuy nhiên, nhiều bản ghi có thể được thêm vào nếu kích thước hàng nhỏ hơn.

— Xylo
nguồn

để lưu trữ nhiều hàng này (1.073.741.824) với giới hạn hàng là 65535, kích thước đĩa cứng cần bao nhiêu? vui lòng đề xuất

— davidb

1

Không thể xác định kích thước đĩa cứng dựa trên số lượng hàng và kích thước hàng. Kích thước bảng sẽ là 64 terabyte. Tuy nhiên, dữ liệu của các cột TEXT và BLOB được lưu trữ tách biệt khỏi hàng và sẽ cần thêm không gian. Ngoài ra, nó sẽ phụ thuộc vào số lượng và loại cột văn bản và BLOB vì kích thước thay đổi tùy thuộc vào loại. Có bốn loại cột văn bản là TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Ngoài ra còn có bốn loại cột BLOB là TINYBLOB, MEDIUMBLOB, BLOB và LONGBLOB.

— Xylo

2

Theo phần Khả năng mở rộng và Giới hạn trong http://dev.mysql.com/doc/refman/5.6/en/features.html , hỗ trợ MySQL cho cơ sở dữ liệu lớn. Họ sử dụng Máy chủ MySQL với cơ sở dữ liệu chứa 50 triệu hồ sơ. Một số người dùng sử dụng Máy chủ MySQL với 200.000 bảng và khoảng 5.000.000.000 hàng.

— Dữ liệu
nguồn

nó có thể hữu ích nếu bạn cũng cho chúng tôi biết loại "Họ" đang sử dụng phần cứng nào

— của tôi_ram

Thật vậy, bạn đúng. Nhưng thật không may, 'họ' không biết gì về phần cứng

— Dữ liệu

@myaccount_ram xin lỗi vì cần thiết điều này, nhưng nếu nó hữu ích tôi đã thấy các giới hạn ít lý thuyết hơn, thực tế hơn về sản xuất MySQL trong thực tế. Tôi đã thấy một cơ sở dữ liệu có ~ 18 tỷ hàng trên các phiên bản AWS 2x db.r4.16xlarge (1 người đọc, 1 người viết). Mỗi máy có 64 lõi CPU, ram 488GB, liên kết mạng 25Gbps, ổ đĩa 64TB. Thang đo db này đã đẩy cả giới hạn kích thước CPU và ổ đĩa và AWS không cung cấp bất kỳ trường hợp tối ưu hóa DB nào lớn hơn. Nó đã được thay thế bằng một lược đồ db đơn giản hơn mà không yêu cầu nhiều hàng.

— Skylar Brown

1

Giới hạn kích thước hàng

The maximum row size for a given table is determined by several factors:

Biểu diễn bên trong của bảng MySQL có giới hạn kích thước hàng tối đa là 65.535 byte, ngay cả khi công cụ lưu trữ có khả năng hỗ trợ các hàng lớn hơn. Các cột BLOB và TEXT chỉ đóng góp 9 đến 12 byte cho giới hạn kích thước hàng vì nội dung của chúng được lưu trữ riêng biệt với phần còn lại của hàng.
Kích thước hàng tối đa cho bảng InnoDB, áp dụng cho dữ liệu được lưu trữ cục bộ trong trang cơ sở dữ liệu, nhỏ hơn một nửa trang. Ví dụ: kích thước hàng tối đa nhỏ hơn 8KB một chút đối với kích thước trang InnoDB 16KB mặc định, được xác định bởi tùy chọn cấu hình innodb_page_size. “ Hạn chế đối với InnoDB Bàn ”.
Nếu một hàng chứa các cột có độ dài thay đổi vượt quá kích thước hàng tối đa của InnoDB, InnoDB sẽ chọn các cột có độ dài thay đổi để lưu trữ ngoài trang cho đến khi hàng phù hợp với giới hạn kích thước hàng của InnoDB. Lượng dữ liệu được lưu trữ cục bộ cho các cột có độ dài thay đổi được lưu ngoài trang khác nhau theo định dạng hàng. Để biết thêm thông tin, hãy xem Lưu trữ Hàng InnoDB và Định dạng Hàng .
Các định dạng lưu trữ khác nhau sử dụng lượng dữ liệu tiêu đề và đoạn giới thiệu trang khác nhau, điều này ảnh hưởng đến lượng lưu trữ có sẵn cho các hàng.

— Saurabh Chandra Patel
nguồn

1

Liên kết http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

Giới hạn kích thước hàng

Kích thước hàng tối đa cho một bảng nhất định được xác định bởi một số yếu tố:

Biểu diễn bên trong của bảng MySQL có giới hạn kích thước hàng tối đa là 65.535 byte, ngay cả khi công cụ lưu trữ có khả năng hỗ trợ các hàng lớn hơn. Các cột BLOB và TEXT chỉ đóng góp 9 đến 12 byte cho giới hạn kích thước hàng vì nội dung của chúng được lưu trữ riêng biệt với phần còn lại của hàng.

Kích thước hàng tối đa cho bảng InnoDB, áp dụng cho dữ liệu được lưu trữ cục bộ trong trang cơ sở dữ liệu, nhỏ hơn một nửa trang cho các cài đặt innodb_page_size 4KB, 8KB, 16KB và 32KB. Ví dụ: kích thước hàng tối đa nhỏ hơn 8KB một chút đối với kích thước trang InnoDB 16KB mặc định. Đối với các trang 64KB, kích thước hàng tối đa nhỏ hơn 16KB một chút. Xem Phần 15.8.8, Giới hạn của những người trên Bảng InnoDB.

Nếu một hàng chứa các cột có độ dài thay đổi vượt quá kích thước hàng tối đa của InnoDB, InnoDB sẽ chọn các cột có độ dài thay đổi để lưu trữ ngoài trang cho đến khi hàng phù hợp với giới hạn kích thước hàng của InnoDB. Lượng dữ liệu được lưu trữ cục bộ cho các cột có độ dài thay đổi được lưu ngoài trang khác nhau theo định dạng hàng. Để biết thêm thông tin, hãy xem Phần 15.11, Lưu trữ Hàng InnoDB và Định dạng Hàng Row.

Các định dạng lưu trữ khác nhau sử dụng lượng dữ liệu tiêu đề và đoạn giới thiệu trang khác nhau, điều này ảnh hưởng đến lượng lưu trữ có sẵn cho các hàng.

Để biết thông tin về các định dạng hàng của InnoDB, hãy xem Phần 15.11, Bộ lưu trữ hàng và định dạng hàng InnoDB, và Phần 15.8.3, Cấu trúc hàng vật lý của InnoDB.

Để biết thông tin về các định dạng lưu trữ MyISAM, xem Phần 16.2.3, Định dạng lưu trữ bảng MyISAM Định dạng.

http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html

— Md Nazrul Hồi giáo
nguồn

-3

Không có giới hạn. Nó chỉ phụ thuộc vào bộ nhớ miễn phí và kích thước tệp tối đa của hệ thống. Nhưng điều đó không có nghĩa là bạn không nên thực hiện biện pháp phòng ngừa trong việc giải quyết việc sử dụng bộ nhớ trong cơ sở dữ liệu của mình. Luôn tạo một tập lệnh có thể xóa các hàng không sử dụng hoặc sẽ giữ tổng số hàng trong một con số cụ thể, giả sử là một nghìn.

— 9 giờ sáng
nguồn

8

Xóa các hàng mà bạn cho là 'không sử dụng' là nguy hiểm và gây ra nhiều vấn đề hơn giải quyết. Một nhà phát triển trước đây trong một trong các dự án của tôi đã thực hiện một kịch bản xóa các giỏ hàng hơn ba ngày tuổi, nghĩ rằng anh ta đang làm đúng. Đoán xem, nó gây ra vấn đề hàng tuần. Chỉ xóa dữ liệu nếu bạn thực sự cần.

— Ben Hitchcock

một trường hợp tồi tệ hơn là khi ai đó bắt đầu lưu trữ đường dẫn tệp trong cơ sở dữ liệu ... hay tất cả các tệp dự án của tôi đã đi đâu .... tôi có một dự án nhỏ bắt đầu từ 3,5 triệu tệp đoán xem ... chúng không phải là tất cả sử dụng thường xuyên.

— Kendrick