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

Question

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

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

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

Извините, если это сбивает с толку, и спасибо за любые советы.

альтернативный текст http://img2.pict.com/b0/57/63/2281110/0/800/dbtable.jpg

Answer 1

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

Answer 2

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

Answer 3

мне просто создать отдельную таблицу настроек?

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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