What is the difference between an table index and a view index?

I am quite confused about the difference between an index on ta开发者_开发百科ble and index on view (Indexed View). Please clarify it.

---

There really is none. The index on both table or view basically serves to speed up searches.

The main thing is: views normally do not have indices. When you add a clustered index to a view, you're basically "materializing" that view into a system-maintained, always automatically updated "pseudo-table" that exists on disk, uses disk space just like a table, and since it's really almost a table already, you can also add additional indices to an indexed view.

So really - between a table and an indexed view, there's little difference - and there's virtually no difference at all between indices on tables and an indexed view.

---

Indexes on views have some restrictions, because views can be based upon various combinations of tables and views.

In either case, they are similar, and as underlying data changes, indexes may or not need to be updated.

Indexes on table are generally always used - typically you will have at least one unique index (primary key) and may have identified one of the indexes to be clustered.

Indexes on views are generally only applied as an optimization technique as view reads become heavy, indexes on the view can improve performance using the views.

---

I've used indexed views to drastically improve the performance of queries where I want to group by a unique combination of fields and maybe calculate some aggregate SUM or count on them.

For example, consider a table that contains customer, truck, distance, date (plus about 30 other performance columns I don't want to query right now). I have hundreds of customers, they have hundreds of trucks each and each truck reports distance and other data 5 times a day. If I want to query a list of which trucks are reporting in which months, I create a view like this:

CREATE VIEW dbo.vw_DistinctUnitMonths
    WITH SCHEMABINDING
AS
SELECT CustomerGroup,
       CustomerId,
       Vehicle,
       CAST(DATEADD(MONTH, DATEDIFF(MONTH, 0, Date), 0) AS DATE) AS Month, --Converts Date to First of the Month
       SUM(CASE WHEN Miles > 0 THEN Miles ELSE 0 END)            AS Miles,
       COUNT_BIG(*)                                              AS Count
FROM dbo.PerformanceData
GROUP BY CustomerGroup, CustomerId, Vehicle, CAST(DATEADD(MONTH, DATEDIFF(MONTH, 0, Date), 0) AS DATE)

GO

CREATE UNIQUE CLUSTERED INDEX IX_DistinctUnitMonths ON vw_DistinctUnitMonths (CustomerGroup, CustomerId, Vehicle, Month)

GO

Here's a slow query that doesn't use the view:

--Can Be Very Slow!
SELECT CustomerGroup,
       CustomerId,
       Vehicle,
       CAST(DATEADD(MONTH, DATEDIFF(MONTH, 0, Date), 0) AS DATE) AS Month
FROM PerformanceData
WHERE Month >= '2020-01-01'
  AND Month < '2020-02-01'
GROUP BY Vehicle, ClientID, ClientGroupId, CAST(DATEADD(MONTH, DATEDIFF(MONTH, 0, Date), 0) AS DATE)

And here is one that runs much faster, because of the indexed view.

--Much Faster
SELECT CustomerGroup,
       CustomerId,
       Vehicle,
       Month
FROM vw_DistinctUnitMonths WITH (NOEXPAND)
WHERE Month >= '2020-01-01'
  AND Month < '2020-04-01'
GROUP BY Vehicle, ClientID, ClientGroupId, Month

Because the indexed view is creating an index on only the unique combinations of customer, group, vehicle and month, the disk space for the view is much smaller than if I were to index those columns on the source table. Queries to the view are faster because the data in the view is concentrated to some tens of megabytes instead of the hundreds of gigabytes the source table occupies.

See also MSFT Docs: Create Indexed Views