Какой запрос будет быстрее

Question

У меня есть таблица пользователей с 17 полями и таблица пользовательских данных с 40 полями, и оба связаны с использованием user_id, который является первичным ключом таблицы пользователя. Они не каскадированы. Обе эти таблицы будут иметь ряды до 400 000 до 500 000 В моем программном обеспечении большую часть времени мне понадобится присоединиться к этим двум таблицам для создания выходов.

Мой вопрос, будет ли мой пробег запрос быстрее, если я удалить таблицу данные пользователя и поставить его поля в таблице пользователей itself.so, что я могу получить результаты с помощью отказа присоединиться запросов

Какой из них лучше 1) все поля в одной таблице ИЛИ 2) два таблиц и с помощью запросов присоединиться к

Answer 1

Я предлагаю вам использовать основную таблицу с только фиксированных полого размера. (Нет полей TEXT BLOB). В большинстве случаев этого должно быть достаточно. Затем вы присоединяетесь только к второй таблице, когда вам нужны эти поля.

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

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

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

Answer 2

Лучше всего поместить все данные в одну таблицу. Кроме того, вы работаете против правил нормализации БД. И почему вы разделили данные об одном пользователе в 2 таблицах? Просто ограничьте результаты SELECT, не используя wildcard selectorr как *, но запишите список с запрошенными полями.

Answer 3

Я не пытаюсь быть смартфоном, но единственным разумным ответом является «попробуй его и измерить для себя».

Вы видите, слишком много неизвестных переменных в вашем вопросе: двигатель

• таблиц (s) (MyISAM, InnoDB, ...)
• дополнительные WHERE условия, если таковые имеются
• дополнительные JOIN s, если они есть
• Структура таблицы («40 полей» - это что-то совсем другое, если они все INT или CHAR или TEXT или VARCHAR или какая-то комбинация).
• существующих индексы
• соотношений чтения/записи на столе (ы), и связанные с этим шумиху (то есть блокировки модель используется)
• и Gazillion других вещей

Try для запуска запросов/запросов с EXPLAIN; план запроса даст вам гораздо более конкретные данные, чем мы могли бы предоставить.

Answer 4

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

Можете ли вы генерировать случайные записи пользователей через скрипт?Если это так, вы можете просто создать 500 000 записей, используя обе схемы (все в одной таблице и две таблицы с объединением) и посмотрите, какая из них самая быстрая. Может быть, разница настолько мала, что нет смысла сливать таблицы.

Answer 5

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

Твердые результаты можно получить только путем бенчмаркинга.

Я могу внести полезный анекдот. В другом задании у нас была пользовательская база данных, которая содержала все данные для одного пользователя в одной строке. Данные пользователя составляли около 1-2K на пользователя, в общей сложности, и у нас было 25 миллионов записей пользователей.

База данных считывает и записывает данные на страницах по 8K каждый (MySQL InnoDB будет 16K страниц, кстати). Это означает, что у нас около 4-6 записей пользователей на странице базы данных и около 5 миллионов страниц данных.

В записи пользователя содержатся поля, в которых хранится время последнего входа пользователей. Между 7 и 9 утрами мы увидим около 8 миллионов уникальных пользователей, которые будут регистрироваться, поэтому нам будет около 8 миллионов страниц, загрязненных и нуждающихся в обратной записи. По существу, каждый день мы возвращаем всю пользовательскую таблицу на диск дважды или трижды.

Мы ввели искусственную связь 1: 1, которая напоминает страницы пользователя и user_details: у нас был пользователь и таблица user_lastlogin. Записи user_lastlogin были очень узкими, состоящими, по существу, только из идентификатора пользователя и (трех разных) последних дней входа пользователя (в зависимости от используемого сервиса). Поскольку user_lastlogin очень узкий, теперь у нас почти тысяча записей на странице и всего 25 000 страниц в таблице. Имея 8 миллионов уникальных логинов, нам теперь нужно записать намного меньше данных (поскольку контрольные точки и обратные записи в базе данных задерживаются). Нагрузка на дисковый ввод-вывод снижалась на порядок.

Извлеченный урок: может быть очень полезно отделить статические данные от изменчивых данных (мы рассмотрели статические данные пароля, так как у нас было около 15 000 изменений пароля в день, тогда как у нас было 8 миллионов обновлений last_login в день).