Быстрый способ выбрать большой объем данных в SQL Server

Question

это схема моей таблицы:

CREATE TABLE [dbo].[ClassifiedDataStore_MasterTesting]
(
[PK_ID] [uniqueidentifier] NOT NULL,
[FK_SubCategory_Master] [int] NULL,
[FK_IntegratedWeb_Master] [int] NULL,
[FK_City_Master] [int] NULL,
[Title] [nvarchar](max) NULL,
[Description] [varchar](max) NULL,
[Url] [nvarchar](max) NULL,
[DisplayUrl] [varchar](max) NULL,
[Date] [datetime] NULL,
[ImageURL] [nvarchar](max) NULL,
[Price] [decimal](18, 2) NULL,
[Fetch_Date] [datetime] NULL,
[IsActive] [bit] NULL,
[record_id] [int] IDENTITY(1,1) NOT NULL,
CONSTRAINT [PK_ClassifiedDataStore_Master2] PRIMARY KEY CLUSTERED 
(
[PK_ID] ASC
) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Answer 1

Ух ты, все эти столбцы MAX ... тебе действительно нужно MAX для URL и заголовков?Вы действительно хотите, чтобы PK был GUID?

Поскольку большинство систем связаны с вводом / выводом, одним из ключей к хорошей производительности (в дополнение к разумной индексации и только извлечению необходимых данных) является подгонка как можно большего количества данных.данные на каждой странице, насколько это возможно.Поскольку все эти столбцы больших объектов хранят потенциально 2 ГБ данных в каждом, каждая выборка страниц будет немного кошмаром для SQL Server.Настоятельно рекомендуем рассмотреть возможность обрезки некоторых из этих типов данных, где это возможно, например,

• использовать столбец IDENTITY вместо GUID, если это возможно, - почему есть оба?
• для любых INT, которые FK ищет для поискакоторый всегда будет иметь <32K строк, используйте SMALLINT </li>
• для любых INT, которые FK для поиска, у которого всегда будет <255 строк, используйте TINYINT </li>
• используйте хранение в строке (а не типы MAX)для таких вещей, как заголовок и URL
• , вы можете сбрить несколько байтов, используя <18 цифр для цены, - сомневаетесь, что у вас будут классифицированные элементы стоимостью $ 1 000 000 000 000 + </li>
• , если для даты не требуется точность <минута/ Fetch_Date, используйте SMALLDATETIME </li>
• , если

(я также нахожу странным, что вам нужен Unicode / nvarchar для заголовка, ноне для описания, и вам нужен Unicode / nvarchar для URL / ImageURL, но не DisplayURL. Можете ли вы объяснить обоснование там? Я дам подсказку: если заголовок может содержать Unicode, то яРазумно предположить, что заголовок также может быть упомянут в описании, поэтому он также должен поддерживать Unicode.И все ваши URL, вероятно, просто отлично, поддерживая только varchar;Я не помню, чтобы когда-либо видел URL с символами Unicode в нем (как правило, они кодируются в URL). *

Рассмотрите возможность использования сжатия данных, если вы используете Enterprise Edition или новее.Опять же, поскольку большинство систем связаны с вводом / выводом, мы рады заплатить небольшое штрафное вознаграждение ЦП за сжатие / распаковку данных, чтобы разместить их на меньшем количестве страниц, это значительно сократит время, необходимое для выполнения тяжелых операций чтения с таблицей.

Answer 2

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

Предположим, что большинство ваших запросов начинаются с фильтрации таблицы по: дате, а затем по названию.

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

Проверьте это объяснение из