Maksymalna liczba rekordów w tabeli bazy danych MySQL


174

Jaki jest górny limit rekordów dla tabeli bazy danych MySQL. Zastanawiam się nad polem autoincrement. Co by się stało, gdybym dodał miliony rekordów? Jak radzić sobie w tego typu sytuacjach? Dzięki!


16
Nie wspominając o 1.21 GIGAWATTS!
Ben

2
Przynajmniej jeśli pamięć jest dostępna, limit jest ustalany przez silnik pamięci masowej, więc (na przykład) używając MyISAM otrzymujesz inny limit niż użycie InnoDB.
Jerry Coffin

77
@ Onion-Knight: Nie zgadzam się. Wstawianie milionów wierszy do jednej tabeli jest normalne , a niektóre bazy danych mają limit, więc warto zapytać. Jeśli ktoś zapyta, czy MySQL obsługuje miliony tabel , to prawdopodobnie jest to oznaka architektonicznego błędu.
Bill Karwin

Odpowiedzi:


61

typy mysql int mogą zrobić całkiem sporo wierszy: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

unsigned intnajwiększa wartość jest 4,294,967,295
niepodpisany bigintnajwiększa wartość jest18,446,744,073,709,551,615


8
2147483647 max, więc jeśli pracujesz z wieloma miliardami wpisów, musisz dokonać autoinkrementacji bigint? (co prawdopodobnie spowodowałoby, że twoje wybrane stwierdzenia stopiłyby się na długo przedtem)
Kzqai

2
@Tchalvak to dla podpisanego int, przeczytaj dokumentację mysql.
Leandro,

8
Kontekst pytania dotyczy tego, czy pole autoinkrementacji może obsłużyć wiele wierszy, a nie ograniczenia innych zasobów
KM.

21
Plakat nie zawiera pytań o numeryczne lub inne typy danych. . Naprawdę nie rozumiem, jak można to oznaczyć jako poprawną odpowiedź. Chociaż muszę przyznać, że pytanie jest niejednoznaczne, powinniśmy rozróżnić między typem danych PK a maksymalną liczbą wierszy w tabeli.
Bery

1
@Bery, OP rozróżnił, czego szukają, wybierając to jako odpowiedź. Najwyraźniej interesowała ich pojemność pola autoinkrementacji, które obejmuje moja odpowiedź, a nie ograniczenia innych zasobów.
KM.

238

Największa wartość liczby całkowitej ma niewiele wspólnego z maksymalną liczbą wierszy, które można przechowywać w tabeli.

Prawdą jest, że jeśli używasz int lub bigint jako klucza podstawowego, możesz mieć tylko tyle wierszy, ile wynosi liczba unikatowych wartości w typie danych klucza podstawowego, ale nie musisz określać swojego klucza podstawowego liczbą całkowitą , możesz uczynić to CHAR (100). Możesz również zadeklarować klucz podstawowy w więcej niż jednej kolumnie.

Oprócz liczby wierszy istnieją inne ograniczenia dotyczące rozmiaru tabeli. Na przykład możesz użyć systemu operacyjnego, który ma ograniczenie rozmiaru pliku. Lub możesz mieć dysk twardy o pojemności 300 GB, który może pomieścić tylko 300 milionów wierszy, jeśli każdy wiersz ma rozmiar 1 KB.

Limity rozmiaru bazy danych są naprawdę wysokie:

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

Silnik pamięci masowej MyISAM obsługuje 2 32 wiersze na tabelę, ale można zbudować MySQL z --with-big-tablesopcją obsługi do 2 64 wierszy na tabelę.

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

Wydaje się, że silnik magazynu InnoDB nie ma ograniczenia liczby wierszy, ale ma ograniczenie rozmiaru tabeli do 64 terabajtów. To, ile rzędów pasuje do tego, zależy od wielkości każdego rzędu.


62
cholera - szkoda, że ​​nie czytałem tego wcześniej ... właśnie przekroczyłem mój rozmiar 64 terabajtów na jednym z moich stołów, a teraz mój system działa tak wolno!
JM4

2 ^ 32 = 4 294 967 295 i 2 ^ 64 = 18 446 744 073 709 551 615, więc ... Największa wartość całkowita ma trochę wspólnego z maksymalną liczbą wierszy. Niekoniecznie klucz podstawowy.
teynon

1
@Tom, InnoDB jest domyślnym silnikiem pamięci masowej w MySQL 5.5 i jest lepszym wyborem w 99% przypadków.
Bill Karwin,

2
@ Ext3h, Sphinx Search jest zwykle lepszym wyborem niż indeksy pełnotekstowe w MyISAM lub InnoDB.
Bill Karwin

1
Dla mysql 8 limit to 256 TB przy rozmiarze strony 64 KB.
UselesssCat

13

Sugeruję, aby nigdy nie usuwać danych. Nie mów, że jeśli tabele są dłuższe niż 1000, obetnij koniec tabeli. Twój plan musi zawierać prawdziwą logikę biznesową, taką jak czas nieaktywności tego użytkownika. Na przykład, jeśli jest dłuższy niż 1 rok, umieść je w innej tabeli. Miałbyś to co tydzień lub co miesiąc w skrypcie konserwacyjnym w środku wolnego czasu.

Kiedy napotkasz wiele wierszy w swojej tabeli, powinieneś zacząć dzielić tabele na fragmenty lub partycjonować i umieszczać stare dane w starych tabelach według roku, np. Users_2011_jan, users_2011_feb, lub użyć liczb dla miesiąca. Następnie zmień programowanie, aby pracować z tym modelem. Może utworzyć nową tabelę z mniejszą ilością informacji, aby podsumować dane w mniejszej liczbie kolumn, a następnie odwołać się do większych tabel podzielonych na partycje tylko wtedy, gdy potrzebujesz więcej informacji, na przykład gdy użytkownik przegląda swój profil. Wszystko to należy bardzo uważnie rozważyć, aby w przyszłości ponowne uwzględnienie nie było zbyt kosztowne. Możesz również umieścić w jednej tabeli tylko użytkowników, którzy cały czas odwiedzają Twoją witrynę, oraz użytkowników, którzy nigdy nie pojawią się w zarchiwizowanym zestawie tabel.


1
W związku z tym bardzo przydatne jest przyjrzenie się partycjonowaniu MySQL: dev.mysql.com/doc/refman/5.6/en/partitioning.html
Wim Deblauwe

10

W InnoDB, z ograniczeniem rozmiaru tabeli do 64 terabajtów i limitem rozmiaru wiersza MySQL 65 535, może istnieć 1 073 741 824 wierszy. Byłaby to minimalna liczba rekordów wykorzystujących maksymalny rozmiar wiersza. Jednak można dodać więcej rekordów, jeśli rozmiar wiersza jest mniejszy.


ile potrzeba do przechowywania tak wielu (1 073 741 824) wierszy z limitem wierszy równym 65535? proszę o sugestię
davidb

1
Wymaganego rozmiaru dysku twardego nie można określić na podstawie liczby wierszy i samego rozmiaru wiersza. Sam rozmiar tabeli wyniesie 64 terabajty. Jednak dane kolumn TEXT i BLOB są przechowywane oddzielnie od wiersza i wymagają dodatkowego miejsca. Ponadto będzie to zależeć od liczby i typu kolumn TEKST i BLOB, ponieważ rozmiar różni się w zależności od typu. Istnieją cztery typy kolumn TEKST, a mianowicie TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT. Istnieją również cztery typy kolumn BLOB, a mianowicie TINYBLOB, MEDIUMBLOB, BLOB i LONGBLOB.
Xylo

2

Zgodnie z sekcją Scalability and Limits w http://dev.mysql.com/doc/refman/5.6/en/features.html , obsługa MySQL dla dużych baz danych. Korzystają z serwera MySQL z bazami danych, które zawierają 50 milionów rekordów. Niektórzy użytkownicy używają serwera MySQL z 200 000 tabel i około 5 000 000 000 wierszy.


mogłoby pomóc, gdybyś poinformował nas również, jakiego rodzaju sprzętu używali „oni”
my account_ram

Rzeczywiście, masz rację. Ale niestety „oni” nic nie mówili o sprzęcie
dane z

@myaccount_ram przepraszam, że to nekromuję, ale jeśli jest to pomocne, widziałem mniej teoretyczne, bardziej praktyczne ograniczenia produkcyjnego MySQL w akcji. Widziałem bazę danych zawierającą ok. 18 miliardów wierszy w instancjach 2x db.r4.16xlarge AWS (1 czytnik, 1 autor). Każda z maszyn miała 64 rdzenie procesora, 488 GB pamięci RAM, łącze sieciowe 25 Gb / s, 64 TB dysku. Ta skala bazy danych przesuwała zarówno limity procesora, jak i rozmiaru dysku, a AWS nie zapewnia żadnych większych wystąpień zoptymalizowanych dla bazy danych. Zastąpiono go prostszym schematem db, który nie wymagał tylu wierszy.
Skylar Brown

1

Limity wielkości wierszy

The maximum row size for a given table is determined by several factors:
  • Wewnętrzna reprezentacja tabeli MySQL ma maksymalny rozmiar wiersza 65 535 bajtów, nawet jeśli silnik pamięci masowej może obsługiwać większe wiersze. Kolumny BLOB i TEXT wnoszą tylko 9 do 12 bajtów w kierunku limitu rozmiaru wiersza, ponieważ ich zawartość jest przechowywana oddzielnie od reszty wiersza.

  • Maksymalny rozmiar wiersza dla tabeli InnoDB, który dotyczy danych przechowywanych lokalnie na stronie bazy danych, to nieco mniej niż połowa strony. Na przykład maksymalny rozmiar wiersza jest nieco mniejszy niż 8 KB dla domyślnego rozmiaru strony InnoDB 16 KB, który jest zdefiniowany w opcji konfiguracyjnej innodb_page_size. „ Ograniczenia dotyczące tabel InnoDB ”.

  • Jeśli wiersz zawierający kolumny o zmiennej długości przekracza maksymalny rozmiar wiersza InnoDB, InnoDB wybiera kolumny o zmiennej długości do zewnętrznego przechowywania poza stroną, dopóki wiersz nie zmieści się w limicie rozmiaru wiersza InnoDB. Ilość danych przechowywanych lokalnie dla kolumn o zmiennej długości, które są przechowywane poza stroną, różni się w zależności od formatu wiersza. Aby uzyskać więcej informacji, zobacz „ Przechowywanie wierszy i formaty wierszy InnoDB ”.
  • Różne formaty przechowywania używają różnych ilości danych nagłówka strony i zakończenia, co wpływa na ilość pamięci dostępnej dla wierszy.

1

Link http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

Limity wielkości wierszy

Maksymalny rozmiar wiersza dla danej tabeli zależy od kilku czynników:

Wewnętrzna reprezentacja tabeli MySQL ma maksymalny rozmiar wiersza 65 535 bajtów, nawet jeśli silnik pamięci masowej może obsługiwać większe wiersze. Kolumny BLOB i TEXT wnoszą tylko 9 do 12 bajtów w kierunku limitu rozmiaru wiersza, ponieważ ich zawartość jest przechowywana oddzielnie od reszty wiersza.

Maksymalny rozmiar wiersza dla tabeli InnoDB, który ma zastosowanie do danych przechowywanych lokalnie na stronie bazy danych, to nieco mniej niż połowa strony dla ustawień 4 KB, 8 KB, 16 KB i 32 KB innodb_page_size. Na przykład maksymalny rozmiar wiersza jest nieco mniejszy niż 8 KB dla domyślnego rozmiaru strony InnoDB 16 KB. W przypadku stron o rozmiarze 64 KB maksymalny rozmiar wiersza jest nieco mniejszy niż 16 KB. Zobacz Sekcja 15.8.8, „Ograniczenia tabel InnoDB”.

Jeśli wiersz zawierający kolumny o zmiennej długości przekracza maksymalny rozmiar wiersza InnoDB, InnoDB wybiera kolumny o zmiennej długości do zewnętrznego przechowywania poza stroną, dopóki wiersz nie zmieści się w limicie rozmiaru wiersza InnoDB. Ilość danych przechowywanych lokalnie dla kolumn o zmiennej długości, które są przechowywane poza stroną, różni się w zależności od formatu wiersza. Aby uzyskać więcej informacji, zobacz Sekcja 15.11, „Przechowywanie wierszy i formaty wierszy w InnoDB”.

Różne formaty przechowywania używają różnych ilości danych nagłówka strony i zakończenia, co wpływa na ilość pamięci dostępnej dla wierszy.

Więcej informacji na temat formatów wierszy InnoDB można znaleźć w sekcji 15.11, „Przechowywanie wierszy i formaty wierszy InnoDB” oraz w sekcji 15.8.3, „Fizyczna struktura wierszy tabel InnoDB”.

Aby uzyskać informacje na temat formatów pamięci MyISAM, zobacz Sekcja 16.2.3, „Formaty pamięci MyISAM Table”.

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


-3

Tu nie ma limitu. Zależy to tylko od ilości wolnej pamięci i maksymalnego rozmiaru pliku w systemie. Ale to nie znaczy, że nie powinieneś podejmować środków ostrożności w radzeniu sobie z zużyciem pamięci w bazie danych. Zawsze twórz skrypt, który może usuwać nieużywane wiersze lub utrzymywać całkowitą liczbę wierszy w ramach określonej liczby, powiedzmy tysiąc.


8
Usuwanie wierszy, które Twoim zdaniem są „nieużywane” jest niebezpieczne i powoduje o wiele więcej problemów niż rozwiązuje. Poprzedni programista w jednym z moich projektów zaimplementował skrypt, który usuwał koszyki sprzed ponad trzech dni, myśląc, że postępuje właściwie. Zgadnij co, co tydzień powoduje problemy. Usuń dane tylko wtedy, gdy naprawdę tego potrzebujesz.
Ben Hitchcock,

gorszy przypadek jest, gdy ktoś zaczyna zapisywać ścieżki do plików w bazie danych ... siano, gdzie się podziały wszystkie moje pliki projektu ... mam mały projekt, który zaczyna się od 3,5 mln plików zgadnij co ... to nie wszystko często używane.
Kendrick
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.