за MySQL а также inoDB двигатель и таблицы, которые чаще всего используют для чтения(не сильно создавать и редактировать сравнивать с запросами на чтение)
таблицы предназначены для платформы блогов (пользователь может создать блог для себя), и вот мои два варианта для схемы таблиц:
например для столовых сообщений:
1: сообщения (id, blog_id, title, content) => Идентификатор только первичный ключ авто
приращение2: сообщения (id, blog_id, title, content) => составной первичный ключ является
(id, blog_id) и я использую триггер перед созданием запроса для увеличения идентификатора
колонка
и в большинстве моих запросов есть два типа где:
1: для получения одного сообщения:
where id=5
для первого решения
where id=2 and blog_id=3
для решения два
2: для получения нескольких сообщений одного блога
where blog_id=3
для первого решения
where blog_id=3
для решения два
вопрос: какой из них лучше для производительности?
пс. если мой вопрос не ясен, скажите, тогда я объясню больше.
Короче говоря, с точки зрения производительности это не имеет значения. С наиболее часто используемыми СУБД и в большинстве сценариев вы не увидите большой разницы между ними.
Однако самое важное, на что следует обратить внимание, — это простота: совместимость и простота использования. Большинство систем и структур ORM настроены для работы с одним столбцом, представляющим собой PK. Поэтому, если вы выберете составной ключ, он всегда требует небольшой настройки. Во-вторых, если вы используете REST-подход в своем веб-приложении, работа с единичными идентификаторами также облегчит вашу жизнь.
Если используется PK «id, blog_id»: тогда ведущим столбцом в вашем индексе является «id».
Если ваш запрос «где blog_id = 3» — это не буду использовать индекс и будет медленным, потому что blog_id не является ведущим столбцом.
Поскольку ID является уникальным значением в таблице, просто укажите его как PK. В противном случае это вводит в заблуждение, кто-то может подумать, что идентификатор не уникальный.
Если ваши запросы будут часто использовать «blog_id» в качестве критерия, то в этом столбце должен быть вторичный индекс.
Автоинкрементный столбец «id» лучше, чем наличие триггера базы данных на мой взгляд. Меньше движущихся частей и меньше кода для написания.