MS SQL选择无效索引

Question

我遇到的问题是usp比简单查询慢得多。我找到了答案here：由于SQL选择了无效索引，因此速度较慢。所以我可以手动选择它，但我想这不是很好，因为索引应该根据统计数据选择，而不是现在更快的查询。我做了UPDATE STATISTICS查询，使用重新编译启动了查询，但手动索引指定只是加快它的速度。

我做错了还是别无他用？

---

补充：关于碎片我得到了这张表：

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

和图像（文本适合复制，图像 - 用于理解）

碎片高达99.2％...... omg，伟大的斯科特......

Answer 1

有时你只需这样做.....但记录下来！

另一件事是重建索引。如果看起来正确的索引是严重碎片的SQL，则不太可能选择它。事实上，我唯一一次过度使用SQL的选择是使用每晚重建的索引，但在使用12小时之后会出现严重碎片。查询突然从＆lt; 1s到＆gt; 60秒，SQL决定停止使用它。总是使用该索引的提示使其返回到＆lt;即使是碎片也是1秒。我们决定最好这样做，然后在当天中间对其进行碎片整理。