Index Strategy for SyteLine Report Tables
SyteLine's default indexes are optimized for transactional operations (insert, update, lookup by primary key), not for the analytical queries that reports demand. Report queries typically filter by date ranges, status values, and master data references that may lack supporting indexes. Adding non-clustered indexes on frequently filtered columns dramatically improves report query performance, but each index adds overhead to write operations.
- Add covering index on SLCos (order_date, stat, cust_num) INCLUDE (co_num, ship_code) for order-based reports
- Create index on SLCoitems (co_num, item, due_date) INCLUDE (qty_ordered, price, unit_cost) for order line queries
- Index SLGlTrans (trans_date, acct, sub_acct) INCLUDE (amount, ref_num) for financial reporting period queries
- Add filtered index on SLJobs (stat) WHERE stat IN ('R', 'S') for active job reporting without scanning closed jobs
- Monitor index usage with sys.dm_db_index_usage_stats to remove unused indexes that add write overhead
Query Plan Analysis and Rewriting
SQL Server's execution plan reveals exactly how the query engine processes your report queries against SyteLine tables. Table scans, key lookups, hash joins, and sort operations are the primary performance killers. Use SET STATISTICS IO ON to measure logical reads, each report query should target under 10,000 logical reads for sub-second execution.
Rewrite techniques include replacing correlated subqueries with JOINs, using CTEs for complex aggregations, and applying TOP/OFFSET for paginated reports.
- Enable SET STATISTICS IO ON and examine logical reads per table to identify the most expensive table accesses
- Replace correlated subqueries against SLCoitems with JOIN to SLCos for order-line reports reducing reads by 90%+
- Use CTEs (Common Table Expressions) to pre-aggregate SLGlTrans by period before joining to dimension tables
- Apply WHERE clause SARGability: use BETWEEN for date ranges instead of DATEDIFF or DATEPART functions on columns
- Add OPTION (RECOMPILE) hint for parameterized report queries with skewed data distribution on filtered columns
Report-Specific Optimization Techniques
SSRS reports and BI tool queries have unique optimization considerations. SSRS multi-value parameters generate IN clauses that can cause poor plan choices when the value list is large. Snapshot isolation prevents report queries from blocking SyteLine's transactional operations.
Pre-aggregated reporting views and indexed views provide materialized results for the most expensive cross-module reports.
- Create indexed views for expensive cross-module aggregations: monthly revenue by customer by product line
- Enable READ_COMMITTED_SNAPSHOT isolation on the SyteLine database to prevent report queries from blocking transactions
- Split complex SSRS reports into multiple datasets to enable parallel query execution against different SL tables
- Implement pre-aggregated staging tables refreshed nightly for executive summary reports spanning all SL modules
- Use SQL Server Query Store to monitor report query plan regression after SyteLine upgrades or index changes
Try it here, free
SyteLine Database Tables Reference
Searchable lookup of the main SyteLine SQL tables, what each holds and its usual business key, for writing queries and reports.
Suffering from slow SyteLine reports? Netray's database experts optimize your queries and indexing strategy, schedule a performance review.