When I do `dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)` I get the following result for Report ID 18698: 

![enter image description here][1]

For this query:

    SELECT * 
    FROM Reports_Documents 
    WHERE ReportID = 18698 option (recompile)

I get a query plan that makes a Clustered Index Seek on `PK_Reports_Documents` as expected. 

But what baffles me is the incorrect value for Estimated Number of Rows:

![enter image description here][2]

According to [this][3]:

> When the sample query WHERE clause value is equal to a histogram
> RANGE_HI_KEY value, SQL Server will use the EQ_ROWS column in the
> histogram to determine the number of rows that are equal to <your value>

This is also the way I would expect it to be, however it seems not to be the case in real life. I also tried some other `RANGE_HI_KEY` values that were present in the histogram provided by `show_statistics` and experienced the same. This issue in my case seems to cause some queries to use very unoptimal execution plans resulting in an execution time of a few minutes whereas I can get it to run in 1 sec with a query hint.

All in all: Can someone explain me why is `EQ_ROWS` from the histogram not being used for the Estimated Number of Rows and where does the incorrect estimate come from?

A bit more (possibly helpful) info: 

* Auto create statistics is on and all the statistics are up to date.
* The table being queried has about 80 million rows.
* `PK_Reports_Documents` is a combination PK consisting of `ReportID INT` and `DocumentID CHAR(8)`

  [1]: https://i.sstatic.net/sdiDW.png
  [2]: https://i.sstatic.net/Srdiq.png
  [3]: http://blogs.technet.com/b/mspfe/archive/2013/04/18/understanding-sql-server-cardinality-estimations-by-charting-histogram-to-actual-values.aspx