Analyzing SQL Server query plan
Welcome to stack exchange. As a general rule, you should try to limit your questions to a single, well-defined question. Here it reads as if you just want general tuning help for your server, which isn't the best fit for the site. Ideally, questions and answers will be useful to a wide audience and will remain relevant over time. With all of that said, I'm going to answer the two discrete questions that you have about the number of logical reads and the significance of query cost.

It is certainly possible to have 15 billion reads on a server over an eight hour period. Those reads are logical reads which represents operations against memory instead of disk. I just ran a random query on my desktop that did about 2 million logical reads in a minute. Extrapolating that out would give me a total of about 58 billion logical reads over an eight hour period.

The query cost is a unitless measure of the expected amount of work that SQL Server will need to complete to execute a query. In general, the number doesn't mean much without context and you don't have to be concerned with it unless there's a problem. It is used by the engine in various ways if you're interested in that. Here's the list I know off the top of my head:


If the query cost is too low it won't be eligible for a parallel plan. This is controlled by the cost threshold for parallelism option.
The number of seconds that a query will wait for a memory grant before throwing an error. There are some configuration options here which can influence it, but the general formula is something like query cost / 25 (rounded in seconds) with a maximum of 86400 seconds (1 day).
The amount of steps taken by the optimizer during query plan creation. The optimizer may do more work in evaluating possible query plans for queries which are expected to be more expensive.
If the query is sent to a small query resource semaphore.
If the query is not able to run due to the query governor cost limit.


In general, you don't have to worry about those details unless something is going wrong. There are a few common cases where the query cost can be useful though. If certain queries aren't going parallel or if too many queries are going parallel then you may need to adjust CTFP based on your workload. If a query is slow and you're able to find a query hint that makes it faster than the difference in costs between two queries can provide useful clues as to why the optimizer didn't naturally select the query plan that you hinted. If a query is very slow with an absurdly slow cost (for example, &lt; 1 unit) that suggests that the optimizer is working off bad information. For example, a cardinality estimate could be way off. If you're able to correct that bad information you might get a more efficient plan.