Home/ Questions/Q 152491
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T09:37:58+00:00

The table in question is part of a database that a vendor’s software uses

  • 0

The table in question is part of a database that a vendor’s software uses on our network. The table contains metadata about files. The schema of the table is as follows

Metadata  ResultID (PK, int, not null)  MappedFieldname (char(50), not null)  Fieldname (PK, char(50), not null)  Fieldvalue (text, null)

There is a clustered index on ResultID and Fieldname. This table typically contains millions of rows (in one case, it contains 500 million). The table is populated by 24 workers running 4 threads each when data is being ‘processed’. This results in many non-sequential inserts. Later after processing, more data is inserted into this table by some of our in-house software. The fragmentation for a given table is at least 50%. In the case of the largest table, it is at 90%. We do not have a DBA. I am aware we desperately need a DB maintenance strategy. As far as my background, I’m a college student working part time at this company.

My question is this, is a clustered index the best way to go about this? Should another index be considered? Are there any good references for this type and similar ad-hoc DBA tasks?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The indexing strategy entirely depends on how you query the table and how much performance you need to get out of the respective queries.

    A clustered index can force re-sorting rows physically (on disk) when out-of-sequence inserts are made (this is called ‘page split’). In a large table with no free space on the index pages, this can take some time.

    If you are not absolutely required to have a clustered index spanning two fields, then don’t. If it is more like a kind of a UNIQUE constraint, then by all means make it a UNIQUE constraint. No re-sorting is required for those.

    Determine what the typical query against the table is, and place indexes accordingly. The more indexes you have, the slower data changes (INSERTs/UPDATEs/DELETEs) will go. Don’t create too many indexes, e.g. on fields that are unlikely to be filtered/sorted on.

    Create combined indexes only on fields that are filtered/sorted on together, typically.

    • 0