Let's go over each mistake [thread]
The "scan" template variable was an earlier attempt to solve the problem of not being able to use timeFilter, to, or from variables inside other template variables. The user would have to select a scan value to modify the other template variable scan range 
This was bad design because users innately just want to select the time range using the date/time picker. Further, it was confusing when they would expand or slide the time range but the template variables would remain the same. The correct solution is to use $__from and $__to
Here's what the template variables look like before/after correcting that error by first deleting the scan variable and using proper variables in the where clauses of other template vars
Still more problems to fix in these template variables though
Next, we need to move the time-based WHERE clauses to the outer queries
Moving the time-based WHERE clause on your subqueries to the outer query can *dramatically* reduce the amount of time to get results depending on how much data is queried (directly affected by the user's time-range choice)
Here's the next problem we need to solve. How to get unique tag values for a given time range. A lot of people want to know how to do this, and this is not the best way (there is a better way)
The best way to get unique tag values in #InfuxDB for a given time range is to use a subquery that groups on the tag and then have the outer query select said tag. You only need one non-tag (non-"time") metric to query on the inner query. Also, use "LIMIT 1" for speed
Here is the final product. These template variables load (all of them) in under one second. Before the changes made in this thread, it would take upwards of 20 seconds to simply complete these queries (which have to be done before the dashboard displays). Now, imagine ...
Imagine you load the dashboard and for 20-30 seconds you see nothing except a spinner. No panels, no graphs, no single-stats, nothing. Now imagine that within a split-second all the panels are visible and loading their data. That's the difference between optimizing your queries
But it does not end with template variables. What's wrong with this panel's query? How can we determine optimization of an individual panel? Take note of the query spinner, learn about "d,r", and adjust query to re-test
Press d then r, watch the spinner. Move the $timeFilter WHERE clause to the outer query. Press d then r, watch the spinner.
Unless your database has almost no data in it, you will see a dramatic difference. When I move $timeFilter to fix this query, the spinner disappears faster
Unless your database has almost no data in it, you will see a dramatic difference. When I move $timeFilter to fix this query, the spinner disappears faster
Here is the fixed query. It returns the same data; the panel looks exactly the same; but it loads 20x faster
But, believe it or not, we can make this query EVEN FASTER!
(kinda feel like I'm working on the million-dollar-man version of Grafana)
It's deceptively simple, but there is absolutely no reason to return more than one epoch in the inner query if we're using distinct() on outer
(kinda feel like I'm working on the million-dollar-man version of Grafana)
It's deceptively simple, but there is absolutely no reason to return more than one epoch in the inner query if we're using distinct() on outer
The lessons in this thread should help you make more performant dashboards (at least if you are using InfluxDB). The other lesson is that you should constantly revisit your queries to improve them when you learn new techniques.
