Which properties make a query a good candidate for search optimization?

• A. Table size 100GB, table is not clustered, table is frequently queried on columns other than the primary cluster key, query runs for 10s of seconds, one column has 100-200k distinct values
• B. Table size 10MB, table is clustered, queries run under a second, distinct values per column are low
• C. Table size 1TB, table is clustered, queries run for hours, distinct values per column are 10
• D. Table size 500MB, table is not clustered, queries run under a second, distinct values per column are 5k

Answer: (A)

Search optimization is most beneficial when you have large data with filters on non-clustered columns and you’re seeing slow query performance. It adds lightweight structures to quickly locate rows for common predicate values without scanning the whole table, which is especially valuable when the data volume is big and the filtered columns are not the clustering keys.

This scenario fits well: a sizable table (100GB) that isn’t clustered, with frequent queries on non-key columns, and some queries taking many seconds. The column with 100–200k distinct values signals high cardinality, meaning there are many selective predicate possibilities that SOS can accelerate. The combination of non-clustered access, high cardinarity predicates, and non-trivial runtime makes it a strong candidate for search optimization.

The other options are less suitable because they either already benefit from clustering and don’t suffer from slow scans (small size or fast queries), or they have low cardinality (few distinct values) which reduces the potential gains from SOS, or they don’t present enough data volume to justify the added optimization.