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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

Вы можете разделить одну основную таблицу на несколько таблиц TRANSACTION, чтобы получить гораздо более быстрый результат, чем сейчас.а также сделать первичный ключ как УНИКАЛЬНЫЙ КЛЮЧ также во всех транзакциях, а также в основных таблицах.Это действительно поможет вам сделать ваш запрос быстрее.

Спасибо.

Answer 4

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

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

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

Answer 5

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

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