MS SQL chooses invalid index

Question

I had a problem that usp is much slower than simple query. I found an answer here: it's slower because SQL chooses invalid index. So i can manualy choose it, but i guess it's not really very good because index should be chosen based on statistics, but not on the query which is faster at now. I did an UPDATE STATISTICS query, launched query with recompile, but manual index designation is only way to speed it.

Am I doing it wrong or i have no other way?

---

Added: about fragmentation i got this table:

database_id object_id   index_id    partition_number    index_type_desc alloc_unit_type_desc    index_depth index_level avg_fragmentation_in_percent    fragment_count  avg_fragment_size_in_pages  page_count  avg_page_space_used_in_percent  record_count    ghost_record_count  version_ghost_record_count  min_record_size_in_bytes    max_record_size_in_bytes    avg_record_size_in_bytes    forwarded_record_count  compressed_page_count
5   181575685   0   1   HEAP    IN_ROW_DATA 1   0   5,84358954125295    87245   134,77405008883 11758362    75,2216456634544    23479827    0   0   150 7912    3048,005    0   0
5   181575685   0   1   HEAP    LOB_DATA    1   0   0   NULL    NULL    2936013 93,9886829750432    3130474 0   0   15  8054    7134,754    NULL    NULL
5   181575685   2   1   NONCLUSTERED INDEX  IN_ROW_DATA 4   0   97,8751333829954    246815  1,00619897494075    248345  93,3990363232024    23480086    1   0   50  96  77,979  NULL    0
5   181575685   2   1   NONCLUSTERED INDEX  IN_ROW_DATA 4   1   99,1716520938794    4317    1,0067176279824 4346    51,3817148505065    248345  0   0   23  88  70,814  NULL    0
5   181575685   2   1   NONCLUSTERED INDEX  IN_ROW_DATA 4   2   97,1830985915493    71  1   71  56,1078206078577    4346    0   0   23  88  72,224  NULL    0
5   181575685   2   1   NONCLUSTERED INDEX  IN_ROW_DATA 4   3   0   1   1   1   63,6026686434396    71  0   0   23  88  70,535  NULL    0
5   181575685   19  1   NONCLUSTERED INDEX  IN_ROW_DATA 4   0   19,0549233753546    54936   3,85679700014562    211877  91,6800222386953    23480096    1   0   37  83  64,979  NULL    0
5   181575685   19  1   NONCLUSTERED INDEX  IN_ROW_DATA 4   1   7,88643533123028    1373    1,15440640932265    1585    57,7796886582654    211877  0   0   33  39  33  NULL    0
5   181575685   19  1   NONCLUSTERED INDEX  IN_ROW_DATA 4   2   37,5    16  1   16  42,8118112181863    1585    0   0   33  33  33  NULL    0
5   181575685   19  1   NONCLUSTERED INDEX  IN_ROW_DATA 4   3   0   1   1   1   6,89399555226093    16  0   0   33  33  33  NULL    0
5   181575685   20  1   NONCLUSTERED INDEX  IN_ROW_DATA 3   0   63,0082139052136    38280   1,52021943573668    58194   94,6888682975043    23480102    1   0   17  17  17  NULL    0
5   181575685   20  1   NONCLUSTERED INDEX  IN_ROW_DATA 3   1   58,0392156862745    161 1,58385093167702    255 70,463244378552 58194   0   0   23  23  23  NULL    0
5   181575685   20  1   NONCLUSTERED INDEX  IN_ROW_DATA 3   2   0   1   1   1   78,7373362984927    255 0   0   23  23  23  NULL    0

and image (text is good for copying, image - for understanding)

fragmentation up to 99,2%... omg, Great Scott...

Answer 1

Sometimes you just have to do that.....but document it!

One other thing to do is to rebuild the indexes. If what seems the right index is badly fragmented SQL is quite unlikely to choose it. In fact, the only time I have over-ridden SQL's choice is with an index that got rebuilt every night, but was badly fragmented after 12 hours use. The query suddenly went from < 1s to > 60s when SQL decided to stop using it. Putting on a hint to always use that index brought it back to < 1s even when it was fragmented. We decided it was better to do this then to defragment it in the middle of the day.