Как бы вы оптимизировали эту таблицу SQL Server 2008 R2

Question

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

Хорошо, сейчас я сначала покажу вам структуру таблицы:

изображение структуры

Хорошо, это следующееВ запросе указано, сколько непрочитанных сообщений имеет пользователь, и этот запрос является наиболее загружаемым ЦП, поскольку он читает при каждой загрузке страницы:

SELECT COUNT([Id]) [Number] 
FROM [MyTable] 
WHERE [ReceiverUserId] = @1 
  AND [ReceiverReaded] = @2 
  AND [ReceiverDeleted] = @3

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

Answer 1

Зачем вообще разрешать пустые значения в этих столбцах - либо они читаются, либо нет. Просто по умолчанию 0. Затем индексируйте на Read / Deleted / ReceivedUser (в таком порядке они будут «разбиты на разделы», если вам нужно много доступа ALL READ, или, если большинство операций чтения только для одного пользователя, поместите индекс на ReceivedUser )

То, что вы хотите сделать, это увидеть, что ваш индекс покрывает. В вашем случае вы можете поместить индекс в столбцы ReceiverUserId и INCLUDE ReceiverReaded и ReceiverDeleted, и он будет охватывать (для этого запроса). В плане выполнения вы должны просто увидеть поиск по индексу, поскольку у вас есть один пользователь.

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

Answer 2

Довольно простое практическое правило оптимизации базы данных - индексировать любой столбец, который появляется как часть предиката в предложении WHERE или в JOIN.Из вашего примера это может быть:

• ReceiverUserId
• ReceiverReaded
• ReceiverDeleted

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

Answer 3

Вам всегда нужны индексы для полей, которые вы ищете, поэтому вы, вероятно, повысите производительность запросов, добавив индексы в [ReceiverUserId], [ReceiverReaded] и [ReceiverDeleted].

Конечно, больше столбцовиндекс, тем медленнее будут ваши ОБНОВЛЕНИЯ и ВСТАВКИ.

Answer 4

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

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

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

Answer 5

1. Индексируйте поля поиска (согласно ответу @ PaulStock).
2. Измените поля tinyint на битовые поля (значение по умолчанию = 0)
3. Ваше тело действительно должно быть nvarchar (4000)? Это ОГРОМНО! Рассмотрим намного более короткие сообщения (например, nvarchar (300) или меньше - для справки, Twitter всего 140).