A Fast Way to select Large Amount of Data in SQL Server - sql-server-2008

Question

this is the schema of my table:
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

Wow, all those MAX columns... do you really need MAX for URLs and titles? Do you really need the PK to be a GUID?
Since most systems are I/O bound, one key to good performance (in addition to sensible indexing and only pulling the data you need) is to fit as much data onto each page as possible. With all these LOB columns storing potentially 2GB of data each, every page fetch is going to be a little bit of a nightmare for SQL Server. Strongly recommend considering trimming some of these data types where possible, e.g.
use an IDENTITY column instead of a GUID if feasible - why have both?
for any INTs that FK to lookups that will always have < 32K rows, use SMALLINT
for any INTs that FK to lookups that will always have < 255 rows, use TINYINT
use in-row storage (and not MAX types) for things like title and URL
you can shave a few bytes by using < 18 digits for price - doubt you will have classified items worth $1,000,000,000,000+
if < minute accuracy is not needed for Date/Fetch_Date, use SMALLDATETIME
if < day accuracy is not needed for Date/Fetch_Date, use DATE
(I also find it odd that you need Unicode/nvarchar for title, but not for description, and you need Unicode/nvarchar for URL/ImageURL, but not DisplayURL. Can you explain the rationale there? I'll give a hint: if the title can contain Unicode then it is reasonable to assume that the title could also be mentioned in the description, so it should also support Unicode. And all of your URLs are probably just fine supporting only varchar; I don't recall ever seeing a URL with Unicode characters in it (these are typically URL-encoded).)
Consider using data compression if you are on Enterprise Edition or better. Again, since most systems are I/O bound, we are happy to pay a slight CPU penalty compressing/decompressing data in order to fit it onto fewer pages, this will greatly reduce the time required to perform heavy read operations against the table.

Answer 2

When discussing performance it's always important to know what kind of queries will be most frequent for your table.
Your searches will be filtered using what columns? Title and Date?
Suppose that most of your queries start by filtering your table by: Date then by Title.
You should create a not unique clustered index using Date in first place and then Title.
Why is that? Because then your records are stored physically sequentially by that order making the searches much faster and that is why you can just have one clustered index per table.
Check this explanantion out