MySQL производительность запросов

У меня есть следующие структуры таблицы:MySQL производительность запросов

EVENT_ID(INT) EVENT_NAME(VARCHAR) EVENT_DATE(DATETIME) EVENT_OWNER(INT)

Мне нужно добавить поле EVENT_COMMENTS которое должно быть текстовое поле или очень большой VARCHAR.

У меня есть 2 места, где я запрашиваю эту таблицу, один находится на странице со списком всех событий (на этой странице мне не нужно отображать поле event_comments).

И еще одна страница, которая загружает все детали для определенных событий, которые мне нужно будет отображать в поле event_comments.

Должен ли я создать дополнительную таблицу с event_id и event_comments для этого события? Или я должен просто добавить это поле в текущую таблицу?

Другими словами, я спрашиваю, есть ли у меня текстовое поле в моей таблице, но я не SELECT, это повлияет на производительность запросов к моей таблице?

источник

2011-01-26 Or Weinberger

Добавление поля в таблицу делает его больше.

Это означает, что:

Таблица сканирования займет больше времени
Меньше записей вмещается в страницу и, следовательно, в кэш, тем самым увеличивая риск промахов кэша

ыбор это поле с соединением, однако, займет больше времени.

Поэтому добавление этого поля в эту таблицу сделает запросы, которые не выбирают его, работают медленнее, а те, которые его выбирают, работают быстрее.

источник

2011-01-26 14:08:53 Quassnoi

Итак, если я сломаю его: в той же таблице: страница списка событий (не выбрав текстовое поле) будет загружаться медленнее, страница сведений о событиях (выбор текстового поля) будет загружаться быстрее. на разных таблицах: страница списка событий будет загружаться быстрее, страница сведений о событиях будет загружаться медленнее. Верный? –

Я ничего не знаю о внутреннем представлении записей в MySQL, но мне не сразу понятно, почему больше столбцов обязательно замедляет сканирование таблиц. Если каждая строка содержит смещения данных столбца и следующую строку в таблице, вы просто говорите о временах поиска() к смещениям или что-то еще происходит? –

@Larry: что быстрее: читать '100' или' 1000' страниц с диска или 'RAM'? – Quassnoi

Вы должны положить его в тот же стол.

источник

2011-01-26 14:06:30

Мне нравится, когда два ответа говорят прямо противоположное. – Pieter888

Ненавижу, когда два ответа говорят прямо противоположное. ;-) –

I ('date (s)% 2 == 0? 'Love': 'hate''), когда два комментария говорят, что обратное –

Да, это влияет на производительность. По крайней мере, согласно опубликованному вчера this article.

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

Это относительный раздел:

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

источник

2011-01-26 14:07:39 Simone

Я не думаю, что слишком много столбцов идет от 4 до 5. Также в вопросе не указывается, что в комментариях не было бы ничтожного значения. –

Я не согласен с этим аргументом в этом контексте. Хотя правильно сделать таблицу больше и увеличить время сканирования, это лишь незначительно, когда индексирование выполняется правильно. когда этот новый столбец не включен в индекс - и я не вижу причины для этого - размер индекса останется прежним. Я даже не думаю, что отношение кеш/ударов является аспектом в этом контексте, потому что независимой таблице также потребуется пространство, а также дополнительный индекс .... –

Я вижу. Хорошо, я оставлю ответ в качестве ссылки для OP. Я считаю, что лучший результат, если производительность важна, заключается в том, чтобы профилировать оба подхода и - если нет явного победителя - предпочесть дополнительный столбец в таблице. – Simone

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

В зависимости от двигателя, капли хранятся в строках (MyISAM), частично за пределами страницы (InnoDB) или полностью за пределами страницы (в некоторых случаях - плагин InnoDB).

Они могут уменьшить количество строк на странице и, следовательно, увеличить количество операций ввода-вывода для удовлетворения некоторого запроса.

Однако, это крайне маловероятно, что вам все равно, поэтому вы должны просто сделать это в любом случае. Сколько строк имеет эта таблица? 10^9? Сколько из них имеют ненулевые значения для blob?

источник

2011-01-26 14:09:10 MarkR

таблица СОБЫТИЙ будет только расти со временем, так что да, допустим, она имеет 10^9 строк. около 75% -80% будут иметь ненулевые значения для blob. –

В этом случае вы, вероятно, должны подумать об этом, когда приблизитесь к 10^9. Сколько строк вы ожидаете в производстве в этом году? – MarkR

Я, вероятно, получу несколько десятков тысяч строк в год. Но тем не менее, мне любопытно, какой из них лучше работает в данной ситуации, когда у меня есть сотни тысяч строк. –

Это не должно быть слишком много ударов, но если вы беспокоитесь о производительности, вы должны всегда запускать несколько benchmarks и запускать EXPLAINs по вашим запросам, чтобы увидеть истинный эффект.

источник

2011-01-26 14:09:17 bhamby

Сколько событий вы ожидали?

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

источник

2011-01-26 14:18:32 stivlo

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

Я оставлю дополнительные комментарии другим экспертам здесь :-), так или иначе, если у вас есть время, вы можете попытаться заполнить таблицу (ы) несколькими сотнями строк и времени для запросов. Только для синхронизации я бы использовал «SELECT SQL_NO_CACHE <остальную часть вашего запроса» (конечно, не на реальном сайте). – stivlo

MySQL производительность запросов

ответ

Смежные вопросы