Сколько записей можно хранить mysql?
Гость
Подскажите сколько записей можно хранить mysql для нормальной работы сайта? В таблице около 15 полей в которых от 20 до 300 символов! Сайт обьявлений короче, можно ли все обьявления хранить в одной таблице?
Дополнено (1). Ну к примеру у меня 5000 обьявлений! НОРМАЛЬНО Потянет одна таблица?
technoraptor
5000 — это совсем немного. Потянет
Андрей Севастьянов
Легко потянет. Даже SQLite потянет — гораздо проще и легче, чем MySQL.
- Сколько записей отимально хранить в одной таблице, если 700 000 mysql справиться?
- В каком формате хранить данные PhP + MySQL. В каком формате хранить дробные числа? Например: 0.25 0.75 1.00 1.5
- Зачем некоторые ретурды хотят хранить в БД абсолютно всё, даже в тех случаях лучше хранить в файле?
- Скольк записей лучше Хранить в MySQL?
- Если 555000000 записей хранить в mysql, долго ли он будет искать нужную информацию по id?
Новые вопросы
- Как упорядочивать номера записей в базе данных mysql?
- Код на PHP + mySQL механизм взаимодействия
- MySQL Error Not connection задолбала
- КАК СОЗДАТЬ СТОЛБЕЦ В MYSQL SAMP
- PHP MySQL выдернуть записи и тут же их удалить вернув результат
Сколько записей в одной таблице может выдержать myslq?
Полагаю что автору вопроса не стоит задаваться вопросом «Сколько записей в одной таблице может выдержать myslq?», потому что он изначально неверный.
Случай (когда вопрос представляет чисто академический интерес) рассматривать не будем.
Следует задаться другими вопросами:
— мне точно нужен MySQL для решения моей задачи?
— во что я упрусь при большом количестве записей — в ограничение по записи или по чтению?
— при каком объеме памяти в сервере MySQL не сможет эффективно доступаться к данным?
— что такое шардинг, партиционирование и репликация?
— как мне бэкапить базы?
— что будет если моя база упадет?
и т.д. в том же направлении.
Ответ написан более трёх лет назад
Комментировать
Нравится 3 Комментировать
Ответы на вопрос 6
1.844E+19 в таблице типа myisam.
У innodb сложнее найти, но есть ограничение на 64Тб на файл, а значит и на таблицу.
Только эти знания вам никакой практической пользы не принесут.
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Под сотню миллионов держит спокойно, но конечно же таблица жестоко оптимизирована для конкретных достаточно простых запросов. InnoDB.
Переходить на другую СУБД, скорее всего, не стоит. Стоит измерить, насколько плачевная ситуация сейчас и можно ли ее изменить. Проанализируйте, какие запросы идут к таблице, насколько быстро они работают, какие основные операции идут (вставка-чтение), нет ли из-за этого забавных эффектов (например, блокировки на MyISAM и на InnoDB сильно отличаются), все ли индексы стоят, нет ли лишних индексов, нельзя ли их уменьшить и т.д. После этого будете принимать решение. Если сейчас у Вас 1 млн, можно забить тестовую базу на 5 млн и посмотреть, сильно ли изменился расклад.
Сколько записей можно хранить в mysql
В процессе предоставления услуг хостинга мы обращаем внимание на наиболее часто встречающиеся ошибки, которые совершают пользователи при разработке своих виртуальных серверов. Одним из «тяжелых» мест для типичного веб-мастера является работа с MySQL-сервером. Обычно изучение принципов функционирования SQL и методов работы с базами данных ведется по литературе, из которой выбираются только актуальные на момент чтения вещи — как соединиться с базой, как сделать запрос, как обновить информацию или добавить новую запись в базу данных и так далее.
Такой подход, конечно, дает желаемый результат — интерфейсы веб-сайта пользователя в итоге оказываются интегрированными с базой данных. Однако не всегда пользователи задумываются о том, насколько оптимально работает их база, как можно оптимизировать происходящие при работе с MySQL процессы и каково будет функционирование виртуального сервера при увеличившейся нагрузке, «наплывах» пользователей в результате, например, «раскрутки» сайта.
Эта статья поможет Вам оптимизировать работу с СУБД MySQL. Изложенный материал не претендует на детальное описание оптимизации MySQL вообще, а лишь обращает внимание на наиболее часто совершаемые пользователями ошибки и рассказывает о том, как их избежать. Более подробно узнать о тонкостях настройки MySQL можно на специализированных страницах, ссылки на которые приведены в конце этой статьи.
Какие данные нужно хранить в MySQL
Не старайтесь поместить в базы данных всю информацию, которая у Вас есть. Например, не нужно хранить там картинки, хоть MySQL это и позволяет. Помещая в базу данных двоичные образы графических файлов, Вы только замедлите работу своего сервера. Прочитать файл с картинкой с диска гораздо проще и, с точки зрения потребляемых ресурсов, экономичнее, нежели соединиться из скрипта к SQL, сделать запрос, получить образ, обработать его и, выдав нужные http-заголовки, показать посетителю веб-сервера. Во втором случае операция выдачи картинки потребует в несколько раз больше ресурсов процессора, памяти и диска. Также стоит помнить о том, что существуют механизмы кэширования веб-документов, которые позволяют пользователю экономить на трафике, а при динамической генерации контента Вы фактически лишаете своих посетителей этой удобной возможности.
Вместо картинок лучше хранить в MySQL информацию, на основе которой можно генерировать ссылки на статические картинки в динамически создаваемых скриптами документах.
Оптимизация запросов
В ситуациях, когда реально требуется получить только определенную порцию данных из MySQL, можно использовать ключ LIMIT для функции SELECT. Это полезно, когда, например, нужно показать результаты поиска чего-либо в базе данных. Допустим, в базе есть список товаров, которые предлагает Ваш интернет-магазин. Выдавать весь список товаров в нужной категории несколько негуманно по отношению к пользователю — каналы связи с интернет не у всех быстрые и выдача лишних ста килобайт информации зачастую заставляет пользователей провести не одну минуту в ожидании результатов загрузки страницы. В таких ситуациях информацию выдают порциями по, допустим, 10 позиций. Неправильно делать выборку из базы всей информации и фильтрацию вывода скриптом. Гораздо оптимальнее будет сделать запрос вида
select good, price from books limit 20,10
В результате, MySQL «отдаст» Вам 10 записей из базы начиная с 20-й позиции. Выдав результат пользователю, сделайте ссылки «Следующие 10 товаров», в качестве параметра передав скрипту следующую позицию, с которой будет делаться вывод списка товаров, и используйте это число при генерации запроса к MySQL.
Также следует помнить, что при составлении запросов к базе данных (SQL queries) следует запрашивать только ту информацию, которая Вам реально нужна. Например, если в базе 10 полей, а в данный момент реально требуется получить только два из них, вместо запроса
select * from table_name
используйте конструкцию вида
select field1, field2 from table_name
Таким образом, Вы не будете нагружать MySQL ненужной работой, занимать лишнюю память и совершать дополнительные дисковые операции.
Также следует использовать ключ WHERE там, где нужно получать информацию, попадающую под определенный шаблон. Например, если нужно получить из базы поля с названиями книг, автором которых является Иванов, следует использовать конструкцию вида
select title from books where author=’Иванов’
Также есть ключ LIKE, который позволяет искать поля, значения которых «похожи» на заданный шаблон :
select title from books where author like ‘Иванов%’
В данном случае MySQL выдаст названия книг, значения поля author у которых начинаются с ‘Иванов’.
Ресурсоемкие операции
Вместе с тем следует помнить, что существуют операции, выполнение которых само по себе требует больших ресурсов, чем для обычных запросов. Например, использование операции DISTINCT к функции SELECT вызывает потребление гораздо большего количества процессорного времени, чем обычный SELECT. DISTINCT пытается искать уникальные значения, зачастую производя множество сравнений, подстановок и расчетов. Причем, чем больше становится объем данных, к которому применяется DISTINCT (ведь Ваша база со временем растет), тем медленее будет выполняться такой запрос и рост ресурсов, требуемых для выполнения такой функции, будет происходить не прямо пропорцонально объему хранимых и обрабатываемых данных, а гораздо быстрее.
Индексы используют для более быстрого поиска по значению одного из полей. Если индекс не создается, то MySQL осуществляет последовательный просмотр всех полей с самой первой записи до самой последней, осуществляя сопоставление выбранного значения с исходным. Чем больше таблица и чем больше в ней полей, тем дольше осуществляется выборка. Если же у данной таблицы существует индекс для рассматриваемого столбца, то MySQL сможет сделать быстрое позиционирование к физическому расположению данных без необходимости осуществлять полный просмотр таблицы. Например, если таблица состоит из 1000 строк, то скорость поиска будет как минимум в 100 раз быстрее. Эта скорость будет еще выше, если есть необходимость обратиться сразу ко всем 1000 столбцам, т.к. в этом случае не происходит затрат времени на позиционирование жесткого диска.
Быстрый поиск строк при использовании конструкции WHERE
Поиск строк из других таблиц при выполнении объединения
Поиск значения MIN() или MAX() для проиндексированного поля
Сортировка или группировка таблицы в случае, если используется проиндексированное поле
В некоторых случаях полностью теряется необходимость обращаться к файлу данных. Если все используемые поля для некоторой таблицы цифровые и формируют левосторонний индекс для некоторого ключа, то значения могут быть возвращены полностью из индексного дерева с намного большей скоростью.
Подробнее об индексировании:
Поддержка соединения
Как Вы наверняка знаете, для работы с MySQL-сервером необходимо предварительно установить с ним соединение, предъявив логин и пароль. Процесс установки соединения может продолжаться гораздо большее время, нежели непосредственная обработка запроса к базе после установки соединения. Следуя логике, надо избегать лишних соединений к базе, не отсоединяясь от нее там, где это можно сделать, если в дальнейшем планируется продолжить работу с SQL-сервером. Например, если Ваш скрипт установил соединение к базе, сделал выборку данных для анализа, не нужно закрывать соединение к базе, если в процессе работы этого же скрипта Вы планируете результаты анализа поместить в базу.
Также можно поддерживать так называемое persistent (постоянное) соединение к базе, но это возможно в полном объеме при использовании более сложных сред программирования, чем php или perl в обычном CGI-режиме, когда интерпретатор соответствующего языка разово запускается веб-сервером для выполнения пришедшего запроса.
Какое максимальное количество записей в БД Mysql
Я новичок в работе с базами данных. У меня есть таблица зарегистрированных пользователей на сайте (users), хотел бы узнать, какое количество пользователей в ней поместиться? В интернете конкретного ответа не нашел.
Отслеживать
задан 26 дек 2018 в 0:34
Максим Закревский Максим Закревский
347 1 1 золотой знак 5 5 серебряных знаков 14 14 бронзовых знаков
Зависит от настроек MySQL , архитектуры бд и Вашего железа. При желании несколько миллиардов. А так, волноваться не стоит. К примеру, MySQL используется Facebook и им хватает.
26 дек 2018 в 0:59
Если очень хочется конкретики то: 4294967295 если делаете по «гайдам» из интернета и оставляете стандартный размер ключа Int32 (Поля ID). А вообще как написано в комментарии выше
26 дек 2018 в 5:19
Для InnoDB внутренний номер записи — 6 байт. Так что на этом движке — 280 триллионов записей на таблицу.
26 дек 2018 в 5:31
Зависит от СУБД MySql, Postgre, MS SQL. В Mysql есть движки БД, от них тоже зависит
4 дек 2019 в 8:30
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
MySQL имеет 2 движка — MyISAM и InnoDB:
- MyISAM — количество записей 2^32 =~ 4.2e+9 , но настройками максимальное количество записей можно увеличить до 2^64 =~ 1.8e+19
- InnoDB — не имеет лимита по количеству записей, есть лимит на размер 1 таблицы — 64 терабайта
Отслеживать
ответ дан 4 дек 2019 в 8:52
81.1k 7 7 золотых знаков 72 72 серебряных знака 153 153 бронзовых знака
-
Важное на Мете
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.10.27.43697
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.