Query performance and indexes
Quick answer
Find slow queries, read the slow log, and add indexes that actually help.
Key takeaways
- Start from the slow query log, not from guesses
- Date boundaries are the cheapest optimisation available
- Composite index order must match the query
- Every index costs something on insert and update
Where slow queries show up
Slow list loads, slow forms and long running jobs usually trace to one query. Start with System Diagnostics slow queries, then look at the transaction log for the same table and time window.
What makes a query slow
Three causes cover most cases: no index on the field being filtered, a query on a large table with no date boundary, and dot-walking or ORs that prevent index use. Sorting on an unindexed field is a close fourth.
Adding indexes properly
Indexes speed reads and cost writes.
- Index fields used in frequent filters and sorts, not every field
- Composite indexes must match the query order to be used
- Test on a cloned instance with production volume, not on an empty dev
- Ask ServiceNow support to review index changes on very large tables
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which is the cheapest first fix for a slow list?
- A. Add an index
- B. Add a date range filter
- C. Increase page size
- D. Rebuild the table
Show answer
B. Add a date range filter
Reducing the row set with a date boundary usually solves it immediately.
What can prevent index use?
- A. Sorting on an indexed field
- B. OR conditions across different fields
- C. Filtering by sys_id
- D. Small result sets
Show answer
B. OR conditions across different fields
ORs across fields often force a scan instead of an index seek.