MySQL: слово оптимизации таблицы 'guest' или memberid в столбце

Question

Этот вопрос относится к MySQL (он допускает много пустых значений в столбце, который является УНИКАЛЬНЫМ, поэтому решение для моего вопроса может немного отличаться).

Есть две таблицы: члены и Таблица2. Участники таблицы имеют: memberid char(20), это первичный ключ. (Пожалуйста, не рекомендуется использовать int (11) вместо char (20) для memberid, я не могу изменить его, он содержит ровно 20 символов).

Таблица2 имеет:

CREATE TABLE IF NOT EXISTS `Table2`
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
    memberid varchar(20) NOT NULL,
    `Time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    status tinyint(4) NOT NULL,
    PRIMARY KEY (`id`)
    ) ENGINE=InnoDB;

Table2.memberid - это слово 'guest' (может повторяться много раз) или значение из members.memberid (оно также может повторяться много раз). Любое значение из столбца Table2.memberid (если не «guest») существует в столбце members.memberid. Опять же, members.memberid уникален. Table2.memberid, даже исключая слова «гость», не является уникальным.

Итак, столбец Table2.memberid выглядит так: «Гость» 'Lkjhasd3lkjhlkjg8sd9' 'Kjhgbkhgboi7sauyg674' «Гость» «Гость» «Гость» 'Lkjhasd3lkjhlkjg8sd9'

Таблица2 содержит только ВСТАВКИ и ОБНОВЛЕНИЯ. Обновляет только статус. Критерии для обновления статуса: установите статус = 0, где memberid = '' и status = 1. Таким образом, он может быть обновлен один раз или не обновляться вообще. Как результат, число ОБНОВЛЕНИЙ меньше или равно (по статистике это в два раза меньше, чем число ВСТАВКИ.

Вопрос только об оптимизации. Вопрос можно разделить на:

1) ВЫ НАСТОЯТЕЛЬНО рекомендуете заменить слово «гость» на NULL или на специальную «xxxxxyyyyyzzzzz00000» (20 символов, таких как «очень специальная и зарезервированная» строка), чтобы вы могли использовать символы ( 20) для Table2.memberid, потому что все значения являются char (20)?

2) А как насчет использования внешнего ключа? Я не могу использовать его из-за значения «гость». Это значение не может быть в столбце members.memberid.

Используя другие слова, мне нужна помощь, чтобы решить:

• Можно ли использовать "гость" (мне нравится это слово) -vs- , выбрав 20-символ-зарезервированную строку, чтобы я мог использовать char (20) вместо varchar (20) -vs- , сохраняя NULL вместо 'guest',

• все значения, кроме 'guest', на самом деле являются внешними ключами. Можно ли использовать эту информацию для повышения производительности?

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

Спасибо.

Добавлено: Ну ... я думаю, что нашел хорошее решение, которое позволяет мне рассматривать memberid как внешний ключ.

Answer 1

1) ВЫ НАСТОЯТЕЛЬНО рекомендуете заменить слово «гость» на NULL или на специальную «xxxxxyyyyyzzzzz00000» (20 символов, таких как «очень специальная и зарезервированная» строка), чтобы вы могли использовать chars (20) дляTable2.memberid, поскольку все значения имеют тип char (20)?

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

Вот вкратце проблема.Самым простым ограничением целостности данных для такого рода проблем является ограничение внешнего ключа.Вы не можете использовать один, потому что "гость" не член.(Идентификаторы участников из одного домена; «гость» не является частью этого домена; вы смешиваете значения из двух доменов.) Использование NULL для идентификации гостя мало помогает;Вы не можете отличить гостей от участников, чей член отсутствует.(Использование NULL для идентификации чего-либо обычно является плохой идеей.)

Если , вы можете использовать специальный 20-значный идентификатор участника для идентификации всех гостей, возможно, было бы разумно сделать это.Возможно, вам повезет, в этом «госте» пять букв.Если вы можете использовать «guestguestguestguest» для гостей, не нарушая логику своего приложения, я бы действительно подумал об этом в первую очередь.(Но вы сказали, что, похоже, вы относитесь к гостям как к зарегистрированным пользователям, что, по-моему, может сломать ситуацию.)

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

В Таблице 2 (и, пожалуйста, do найдите более подходящее имя, чем это), индекс на memberid или составной индекс на memberid и status будут выполнятьпочти так же, как вы можете ожидать.Я не уверен, поможет ли составной индекс;«status» имеет только два значения, поэтому он не очень избирателен.

все значения, кроме 'guest', на самом деле являются внешними ключами.Можно ли использовать эту информацию для повышения производительности?

Нет, это не внешние ключи.(См. Выше.) Истинные внешние ключи помогут с целостностью данных, но не с производительностью SELECT.

«Повышение производительности» в значительной степени бессмысленно.Производительность - это балансирование.Если вы хотите повысить производительность, вам нужно указать, какую часть вы хотите улучшить.Если вы хотите более быструю вставку, удалите индексы и ограничения целостности.(Не делайте этого.) Если вы хотите более быстрые операторы SELECT, создайте больше индексов.(Но больше индексов замедляет вставки.)

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

Может помочь настройка вашего сервера.Но следите за общей эффективностью.Не стоит слишком увлекаться ускорением одного запроса, чем снижать производительность во всех остальных.В идеале, напишите тестовый набор и решите, какая скорость достаточно хороша, прежде чем приступать к тестированию.Например, скажем, у вас есть один запрос, который занимает 30 секунд.Какое приемлемое улучшение?20 секунд?15 секунд?2 миллисекунды звучат хорошо, но вряд ли цель для запроса, который занимает 30 секунд.(Хотя я наблюдал такой рост производительности при переходе к улучшенной структуре таблиц и индексов.)