Будет ли результат в базе данных MySQL замедлен по сравнению с количеством столбцов в таблице?

0

Используя PHP, я создаю приложение, которое является ресурсом базы данных MySQL тяжелым, но мне также нужны его данные, чтобы быть очень гибкими. В настоящее время существует несколько таблиц, которые имеют массив разных столбцов (включая текст, longtext, int и т.д.), И в будущем я хотел бы расширить число столбцов этих таблиц, когда новые группы данных требуется.

Мой вопрос: , если у меня есть таблица с, скажем, 10 столбцами, и я буду расширять ее до 40 столбцов в будущем, будет ли значительно замедлен SQL-запрос (через PHP)?

Пока начальный, маленький запрос, который ищет только начальные 10 столбцов, не является запросом SELECT-all (*), я хотел бы знать, используется ли больше ресурсов или обработки, потому что исходная таблица теперь много больше.

Кроме того, будет ли база данных в целом работать медленнее или будет намного больше из-за того, что многие столбцы теперь постоянно остаются как значения NULL (например, когда вставлена ​​новая запись, которая требует только первые 10 столбцов)?

  • 0
    Что касается гибкого хранилища данных, вас может заинтересовать этот вопрос SO: stackoverflow.com/questions/3455168/…
  • 0
    Вам нужно изменить структуру вашей хромой таблицы. Новые группы данных должны обрабатываться как дополнительные строки в связанных таблицах, а не как дополнительные столбцы. Это вопрос архитектуры базы данных, а не производительности.
Показать ещё 1 комментарий
Теги:
database
database-design

5 ответов

1
Лучший ответ

MyISAM и InnoDB ведут себя по-разному в этом отношении по различным причинам.

Например, InnoDB будет разделять дисковое пространство для каждого столбца на диске независимо от того, есть ли в нем данные, а MyISAM будет сжимать таблицы на диске. В случае, когда имеется большое количество пустых столбцов, InnoDB будет тратить много места. С другой стороны, InnoDB делает блокировку на уровне строк, что означает, что (с оговорками) одновременное чтение/запись в одну и ту же таблицу будет работать лучше (MyISAM делает блокировку на уровне таблицы при записи).

Вообще говоря, вероятно, неплохо иметь много столбцов в одной таблице, особенно по причинам волатильности. Например, в InnoDB (возможно, MyISAM тоже?), Переустановка столбцов или изменение типов столбцов (т.е. varchar 128varchar 255) в середине таблицы требует, чтобы все данные в столбцах справа перемещались на диске, чтобы сделать (или удалить) пространство для измененного столбца.

Что касается вашего общего дизайна базы данных, лучше всего использовать как можно больше столбцов not null, что экономит пространство (вам не нужен флаг null в столбце, и вы не храните пустую данных), а также увеличивает производительность запросов и индексов. Если у многих записей будет определенный столбец с нулевым значением, вероятно, вы должны переместить его в отношение внешнего ключа и использовать JOIN. Таким образом, дисковое пространство и служебные данные индекса возникают только для записей, которые фактически хранят информацию.

1

Вероятно, лучшим решением было бы создать новую таблицу с дополнительными полями и JOIN таблицы при необходимости. Исходная таблица остается неизменной, сохраняя ее скорость, но вы все равно можете добраться до дополнительных полей.

0

По всей вероятности, он не будет значительно замедлен.

Однако лучше задать вопрос: какой метод добавления большего количества полей приводит к более элегантному, понятному, поддерживаемому и экономически выгодному решению?

Обычно ответ "Это зависит". Это зависит от того, как доступны данные, как будут изменяться требования, как обновляются данные и как быстро растут таблицы.

0

Оптимизация - не мелочи. Ничего нельзя предсказать.

В общем случае короткий ответ: да, он будет медленнее (потому что СУБД, по крайней мере, нужно читать с диска и отправлять больше данных, очевидно).

Но это очень зависит от каждого конкретного случая, насколько он будет медленнее. Вы можете даже не видеть разницу, или получить ее в 10 раз меньше.

-1

вы можете разделить одну главную таблицу на несколько таблиц TRANSACTION, чтобы получить гораздо более быстрый результат, чем сейчас. а также сделать первичный ключ как UNIQUE KEY также во всех транзакциях, а также в основных таблицах. это действительно поможет вам быстрее сделать запрос.

Спасибо.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню