Должен ли я разбивать большую таблицу mysql на несколько?

Question

У меня есть довольно большой сайт социальной сети, над которым я работаю около 2 лет (высокий трафик и 100 файлов). Я экспериментировал последние пару лет с настройкой для максимальной производительности трафика, и я узнал много. Теперь у меня есть огромная задача, я планирую полностью переконфигурировать свою социальную сеть, поэтому я перепроектирую mysql DB и все такое.

Ниже приведена фотография, составленная из нескольких таблиц mysql, на которых у меня есть вопрос. В настоящее время у меня есть таблица входа, которая используется в процессе входа в систему, как только пользователь заходил на сайт, который очень редко нужно ударять по таблице, если не редактировать электронную почту или пароль. Затем у меня есть таблица пользователей, которая в основном является настройками пользователей и данными профиля для сайта. Здесь у меня есть вопросы, должна ли лучшая производительность разбивать таблицу пользователей на меньшие таблицы? Например, если вы просмотрите таблицу пользователя, вы увидите несколько полей, которые я обозначил как «setting_», если я просто создаю отдельную таблицу настроек? У меня также есть поля, отмеченные «count», которые могут быть общим количеством комментариев, фотографий, друзей, почтовых сообщений и т. Д. Так что я должен создать другую таблицу для хранения всего общего количества вещей?

Причина, по которой я все их на 1 столе теперь, потому что я думал, может быть, было бы лучше, если бы я мог сократить запросы mysql, вместо того, чтобы ударить 3 таблицы, чтобы получить информацию о каждой загрузке страницы, я мог бы нанести удар 1.

Извините, если это смущает и благодарит за любые советы.

alt text http://img2.pict.com/b0/57/63/2281110/0/800/dbtable.jpg

Answer 1

Должен ли я просто создать отдельный установочный стол?

Должен ли я создать другую таблицу для хранения всего общего количества вещей?

Для этого нет ни одного правильного ответа, это зависит от того, как работает ваше приложение.

Что вы можете сделать, это измерить и экстраполировать результаты в среде dev.

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

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

О графе Я думаю, что это нормально, если оно есть, хотя всегда говорят, что лучше рассчитать этот материал, я не думаю, что для этой ситуации вам было больно.

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

Answer 2

Вам нужно сравнить результаты тестирования производительности между следующими:

1. Оставив его в покое
2. разбивая его на две таблицы
3. Использование различных запросов, чтобы получить логин данные и данные профиля (если вы этого не делаете) со всеми данными в той же таблице

Кроме того, вы можете реализовать какую-либо стратегию кэширования данных профиля, если данные об использовании предполагают, что это будет выгодно.

Answer 3

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

Answer 4

До тех пор, пока вы не сделаете SELECT * FROM, ваши таблицы, имеющие 2 или 100 полей, не повлияют на производительность. Только SELECTтолько поля, которые вы собираетесь использовать, и все будет в порядке с вашей текущей структурой.

Answer 5

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

Answer 6

Следует учитывать средний размер одной строки, чтобы узнать, дорого ли это извлечение. Кроме того, следует попытаться использовать индексы при поиске данных ... Самое главное - правильно спроектировать, а не просто разделять, потому что «он выглядит большим». Возможно, IP или IP-адреса могут попасть в другое место ... зависит от сохраненных там данных.

Кроме того, как socialnetworksite с использованием этих данных также обрабатывает AUTH и авторизацию процессы (так думает), разделение между входом и пользовательскими таблицами должно предложить хорошую производительность, потому данные о входе в системе „достаточно короткий“, в то время как доступ к профилю может быть выполнен только один раз, сразу после успешного входа в систему. Просто сделайте правильные трюки, чтобы улучшить производительность БД, и это сделано.

(Не забудьте представить таблицы как субъектов, назвать их как единое целое, а не как набор из них)

Answer 7

Две вещи, которые вы будете хотеть, чтобы учитывать при принятии решения, хотите ли вы, чтобы разбить одну таблицу в несколько таблиц:

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

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

Я не могу найти ресурс в Интернете, чтобы обосновать это следующее утверждение, но я вспоминаю в производительности говорить MySQL задается Jay Pipes, что он сказал, что оптимизатор MySQL имеет проблемы, как только вы получите больше, чем 8 соединяет в единственный запрос (MySQL 5.0. *). Я не уверен, насколько точным является это магическое число, но независимо от того, что соединения обычно занимают больше времени, чем запросы из одной таблицы.