如何重新索引 AuditLog 表？ 非聚集主键、聚集覆盖索引、guid

Question

Using SQL Server 2016 Standard. I have an existing AuditLog table, with a PK on a bigint column (generated C# side) and an additional index.

CREATE TABLE [dbo].[AuditLog]
(
    [Id] [bigint] NOT NULL,
    [ChangeTime] [datetime] NOT NULL,
    [User] [varchar](100) NOT NULL,
    [RootId] [bigint] NOT NULL,
    [EntityId] [bigint] NOT NULL,
    [EntityName] [varchar](100) NOT NULL,
    [Operation] [varchar](100) NOT NULL,
    [OldValue] [varchar](max) NULL,
    [NewValue] [varchar](max) NULL
)

ALTER TABLE [dbo].[AuditLog] 
    ADD CONSTRAINT [PK_AuditLog] 
        PRIMARY KEY CLUSTERED ([Id] ASC)

CREATE NONCLUSTERED INDEX [IX_AuditLog_RootId] 
    ON [dbo].[AuditLog] ([RootId] ASC)

With the current 105,000,000 rows, the sizes are (using used_page_count * 8K per page):

• PK_AuditLog: 11,535,112 KB
• IX_AuditLog_RootId: 2,370,480 KB

I now have to create rows in this table from a stored procedure in SQL, not in c# only anymore, so I need a primary key that can be generated SQL side (and C# still). I think my choices are int identity and guid (with a NEWSEQUENTIALID default).

Since most of my usages include the date and ordering by date, I'm thinking of clustering with that. Sounds right?

And since I almost always filter by RootId and User , I'm thinking of including them in my index. Is it a good idea to include the other columns in the clustered index? or should they be in a separate covering index?

Every index needs to identify rows uniquely, so my clustered index will include the primary key even if I don't specify it. So using a Guid as the PK seems a bad idea for storage, particularly with 100million rows. So I'm using a bigint .

Since my PK is notclustered (therefore not stored physically in that order), how does SQL Server work out the next identity? I doubt it sorts the PK to find the max value. Is using identity on a nonclustered column a bad idea?

Also, I guess I could use datetime2 with precision 3 (storage 7 bytes) instead of datetime (8 bytes) to keep same precision but save a bit of space (or even precision 4 to increase precision for same storage anyway)?

So I'm thinking of doing:

CREATE TABLE dbo.AuditLog
(
    Id bigint NOT NULL IDENTITY (1, 1),
    ChangeTime datetime2(4) NOT NULL...


ALTER TABLE AuditLog   
    ADD CONSTRAINT [PK_AuditLog] 
        PRIMARY KEY NONCLUSTERED (Id)

CREATE CLUSTERED INDEX CIX_AuditLog_ChangetimeRootUser 
    ON AuditLog(Changetime, RootId, [User])

Footnote

This is how the table is used:

• No foreign keys to or from this table.

• insert heavy (any add/edit/delete of user entity fields inserts a new AuditLog row, constantly during business hours, must be fast)

• occasional reads (users check what or who changed something, ie, read the AuditLog, a few times a day, would be nice to not wait ages for a query to return)

• AuditLog rows are never updated nor deleted once inserted.

Typical filters and order:

• filter by date only
• filter by date and user
• filter by date and objectId
• filter by date and user and objectId
• filter by objectId only
• almost always sorted by reverse date, to show most recent changes first.
• often used with paging, using "offset x rows" and "fetch next x rows only"
• and a specific use case, which amounts to selecting a subset of PK using a where clause, and then self join on the main table using the PK to retrieve column values

PS: I'm clear on the process and the time it will take, create temporary new table, copy data in chunks, create indexes, etc...

Answer 1

Since most of my usages include the date and ordering by date, I'm thinking of clustering with that. Sounds right?

There is no way to know without doing it and evaluating the results.

Is it a good idea to include the other columns in the clustered index?

You cannot include columns in the clustered index because it makes little sense. The clustered index is ultimately the table. You include columns in a NC index to avoid additional lookup to access other columns of the rows.

how does SQL Server work out the next identity?

Quite frankly, don't worry about it. The engine manages the identity at the table level - it does not need to refer to any specific rows to determine the next value.

Also, I guess I could use datetime2 with precision 3 (storage 7 bytes) instead of datetime (8 bytes) to keep same precision but save a bit of space (or even precision 4 to increase precision for same storage anyway)?

DO NOT handicap your data just to save a single byte per row. Choose the correct datatype according to your requirements. Storage is cheap. A lack of precision is forever.

In addition, your footnotes are not clear. You refer to add/update/delete of user entity fields (which is a meaningless term to those unfamiliar with your schema) and also to "never updated nor deleted". That seems to be a contradiction, which may or may not be relevant.

And one final comment. Change involves risk. If your current schema is sufficient, then the safest approach is to simple recreate your table with your ID column as an identity (and everything else remains the same).