Analyzing SQL Server query plan I ran the sp_BlitzCache script from the Brent Ozar toolkit on a server that I am monitoring (I am new at the company for about 3 weeks). The result of the procedure has the following values:
╔═════════╦═════════════╦═══════════════════╦══════════════════╦════════════════╦══════════════╦════════════╦═════════════════════╦═══════════════════╦═════════════════╦═════════════╦═══════════╦═════════════╗
║  Cost   ║ #Executions ║ Executions/Minute ║ Execution Weight ║ Total CPU (ms) ║ Avg CPU (ms) ║ CPU Weight ║ Total Duration (ms) ║ Avg Duration (ms) ║ Duration Weight ║ Total Reads ║ Avg Reads ║ Read Weight ║
╠═════════╬═════════════╬═══════════════════╬══════════════════╬════════════════╬══════════════╬════════════╬═════════════════════╬═══════════════════╬═════════════════╬═════════════╬═══════════╬═════════════╣
║ 47,4959 ║      212068 ║ 416,6365          ║ 10,9146          ║ 21883508.2710  ║ 103.1910     ║ 61,4143    ║ 47839177.6180       ║ 225.5841          ║ 73,0647         ║ 15372027688 ║     72486 ║ 66,6277     ║
╚═════════╩═════════════╩═══════════════════╩══════════════════╩════════════════╩══════════════╩════════════╩═════════════════════╩═══════════════════╩═════════════════╩═════════════╩═══════════╩═════════════╝

I took these values about 4pm. I have a column that indicates the plan was created about 8am (8 hours window).
I verified that we have the total reads value = to &quot;15372027688&quot;. Is this possible? In the space of 8 hours, I have about 15 billion reads? I have the CPYU weight with the value = 61,4143 and the cost = 47,4959
Can anyone explain to me better the cost of the query, what it means? Is about the cost threshold of parallelism?
Also have the warnings running the procedure:
Warnings

Missing Indexes (3)
Parallel
Downlevel CE (the database is in Compatibility Level 110 while running on a SQL Server 2014 instance) and is running OUTSYSTEMS databases)

I also run performance counters on the server and have about 1400 connections into the SQL Server instance. On the network adapter traffic I have the total bytes in about 92 000 000, 00/sec.
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.