Максимальное количество таблиц в базе данных MySQL
Плохо ли иметь слишком много таблиц в базе данных? У меня около 160 таблиц в одной базе данных. Лучше ли разбить его на несколько баз данных, а не использовать одну базу данных? Единственная база данных для меня удобнее.
5 ответов
Там не являются ограничениями сервера по количеству таблиц в базе данных MySQL. У вас определенно не будет проблем с 160 таблицами, и вам не нужно разделить их на несколько баз данных.
Вы не сможете повысить производительность, разделив свои таблицы на несколько баз данных. Если производительность остается проблемой, вы можете рассмотреть использование табличных таблиц таблиц для размещения некоторых наборов таблиц на разных физических дисках.
MySQL не имеет ограничений на количество таблиц. Основная файловая система может иметь ограничение на количество файлов, представляющих таблицы. Отдельные двигатели хранения могут устанавливать ограничения, зависящие от двигателя. InnoDB позволяет до 4 миллиардов таблиц.
160 таблиц не являются радикально большими.
16 000 может быть. вероятно, будет. более необоснованным — такие базы данных существуют в системах ERP или CRM (даже в диапазоне таблиц 40-50K, но многие из этих таблиц фактически не используются или только используется).
Тем не менее, типичная СУБД будет «обрабатывать» такие большие базы данных, но в таких системах больше системного каталога, чем обычно.
У меня около 7000 таблиц в одной базе данных без каких-либо вредоносных эффектов, за исключением отображения списка таблиц в phpMyAdmin, который занимает некоторое время.
160 все еще в порядке. это делает команду SQL более быстрой, чем создание слишком большого количества содержимого в одной таблице. В моем случае у меня 8,545,214 таблиц в одной базе данных Mysql. Я не хочу хранить миллионы пользователей в одной базе данных, поэтому я использовал несколько таблиц для хранения каждой записи, которую сделал пользователь. это делает MySQL быстрее, чем поиск в одной таблице с миллионами строк.
Сколько всего желательно иметь таблиц в базе данных
Есть база данных состоящая из 5 таблиц. В одной храниться порядка 10+ млн записей. Количество записей, кот. нужно еще заполнить, порядка 120-150 млн. Где каждая новая запись записывается на опр. время дольше, чем предыдущая, т.к. идет проверка на дубликаты.
И поэтому у меня два пути, оставить как есть и ждать пару недель на сохранения инфы. Или же создать, условно говоря пару тысяч таблиц, для мобильности самой бд, т.к. там используются порядка 2-х тысяч разных типов инфы.
И вот для каждого типа инфы, будет использоваться своя таблица. Но не уверен, правильное ли решение.
Как поступить? Может есть третье, четвертое и т.д. решение.
Если вы можете сразу определить тип инфы с помощью безнес логики то лучше обращаться непосредственно к той таблице у которой этот тип инфы определен. Маленький размер таблицы удобнее использовать. Но если бизнес логика хромает, то время затраченное на поиск нужного типа инфы не окупается по сравнению с индексным поиском этого типа инфы в таблице.
Есть база данных состоящая из 5 таблиц. В одной храниться порядка 10+ млн записей. Количество записей, кот. нужно еще заполнить, порядка 120-150 млн. Где каждая новая запись записывается на опр. время дольше, чем предыдущая, т.к. идет проверка на дубликаты.
Если я верно понимаю, то речь идёт о процессе заполнения имеющейся структуры имеющимися данными, и хочется ускорить этот процесс.
В таком случае настоятельно рекомендую выполнить импорт данных во временную структуру без проведения каких-либо проверок (Для MySQL импорт 150кк записей такой простой структуры с применением LOAD DATA INFILE выполняется достаточно быстро), затем выполнить средствами SQL требуемые проверки с удалением дубликатов (и предварительно — необходимые индексирования для быстрого выполнения этих операций), и, наконец, перенос заведомо корректных очищенных данных в боевую таблицу. Для указанных количества и структуры цена вопроса — порядка 3-4 часов.
для каждого типа инфы, будет использоваться своя таблица
А вот тут — полная неясность. Но с учётом того, что
тип информации, это условно говоря, марка телефона, таких марок около 2-х тысяч
скорее всего речь ведётся о простом словаре — тогда вполне достаточно к основной таблице цен иметь ещё одну таблицу с типами телефонов. Но уж никак не две тысячи.
Сколько таблиц можно создать в базе данных MySQL?
MySQL есть нет ограничения на количество баз данных. базовая файловая система может иметь ограничение на количество таблиц. Отдельные механизмы хранения могут накладывать ограничения, специфичные для двигателей. InnoDB позволяет до 4 миллиардов таблиц.
и сколько столбцов можно создать в таблице mysql ?
есть жесткий ограничение 4096 столбцов на таблицу, но эффективный максимум может быть меньше для данной таблицы. Точный предел зависит от нескольких взаимодействующих факторов.
сколько строк можно вставить в таблицу mysql ?
количество строк ограничено максимальный размер для таблицы. Это зависит от ОС. Вы можете наложить ограничение на количество строк, установив MAX_ROWS при создании таблицы время.
ссылки: ограничения в MySQL
Это действительно зависит от операционной системы и версии MySQL. Обычно размер файла MySQL для таблиц может быть: (версия 5.0)
неограниченный. 4096 столбцов. Количество строк лимита мне неизвестно.
Hard cap 4096 столбцов, но мой опыт: попробуйте не использовать VARCHAR, используйте TINYTEXT. В противном случае вы легко достигнете предела «65,535-байтового предела размера строки», даже если у вас меньше 50 столбцов в таблице.
MySQL. Сколько же таблиц оптимально?
С MySQL как-то немного работал, XML за глаза хватало. Но вот сейчас озадачился таким вот практическим вопросом. Сколько таблиц в одной БД оптимально хотя бы для форума? Ведь можно все посты хранить в одной таблице, но тогда при сложном поиске будет сканироваться все таблица. Время, тормоза. можно каждую ветку форума выделить в отдельную таблицу. а ведь можно на каждый сутки создания тем создавать по отдельной таблице. Но не получиться ли так, что скорость обработки запросов к многотабличной БД будет такая же как и для малотабличной ввиду времени выбора нужно таблицы? Но для малотабличной БД запросы создавать проще, не получиться ли так, что с малотабличной БД будет проще работать?
Собственно понятно, что для одних задач более оптимальные это многотабличные БД, для других более оптимально юзать малотабличные. Вот и интерисует мнение тех, кто с БД много работал, т.е. практическая сторона. В каких случаях лучше делать кучу таблиц, в каких лучше мало?
Просто вот думаю. есть БД каталог в которой есть список товаров, список покупателей и покупки (таблица которая связывает таблицу товаров и покупателей). Я вот думаю, лучше сделать все покупки в одной таблице, или, например, для каждый суток создавать отдельную новую таблицу? Ибо потом еще нужно в админке генерировать отчеты по дня и если у нас каждый новые сутки будет новая таблица, то выбрать нужные сутки будет просто, если таблица одна, то придется сканить всю таблицу (ну или её часть учитывая что первичный ключ это время в *них формате).
17 ответов
Нет, не будет. В базах данных как правило нет нужды читать всю таблицу, чтобы выбрать несколько строк. Сложность при этом заключается лишь в правильной расстановке индексов. Например, если у тебя в таблице есть поля «сообщение»,»id пользователя»,»id ветки» (разумеется, их на практике должно быть куда больше, но ограничимся пока этим), то если тебе часто приходится читать из таблицы запросом типа select . where ‘id_ветки’=. , то при наличии индекса на поле id_ветки запрос будет произведён очень быстро при многогигабайтной таблице.
Одну таблицу и правильную расстановку индексов. Если размер таблицы перевалил за несколько гигабайт, то можно архивировать старые данные в другую таблицу.
За первичный ключ в timestamp надо расстреливать на месте. В MySQL есть auto_increment, в Oracle-последовательности и триггеры (а, вероятно, и более простой способ) — в любом случае в каждой нормальной БД вопрос генерации первичных ключей решён.
Применительно к данному случаю рекомендую:
Заменить timestamp на time и date. А если MySQL умеет строить частичные индексы по datetime (в чём я сомневаюсь), то на него.
Внимательно прочитать http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html и расставить соответствующие индексы. В целом, согласно содержимому этой ссылки, индексы на сбалансированных бинарных деревьях будут использоваться и при выражениях timestamp<. and timestamp>=. но всё же рекомендую сделать по-человечески.
Да, и не забудь сделать внешние ключи для контроля целостности данных — по-моему, индексы на внешние ключи MySQL использует автоматически.
Вообще возможности баз данных сильно отключаются от XML — применительно к веб-ресурсам здесь важна устойчивость к многопоточному доступу (когда много клиентов одновременно читают/пишут данные из одной таблицы), чему помогают блокировки, транзакции и методы их разрешения.
Однако в силу вопроса, выдающего твою низкую квалификацию в этой области, очень рекомендую почитать литературу по базам данных, так как неправильное проектирование таблиц может повлечь очень плачевные последствия в плане объёма переписываемого кода. Также как альтернативу можешь освоить библиотеки ORM (объектно-реляционного отображения), которые вбирают себя работу со многими типичными случаями без необходимости писать запросы вручную. К сожалению, я не знаю очень хорошей библиотеки для PHP, но если тебе вэтом вопросе так ничего и не посоветуют, можешь попробовать phpdoctrine, однако сразу предупреждаю, что по тупости её разработчика в персистентных классах там нельзя использовать свои конструкторы.