In the data model section, we have listed some best practices. Tags in InfluxDB are indexed. When the query has certain search fields frequently used, consider storing it as a tag. Many GROUP BY aggregations are expensive, for those GROUP BY fields, consider storing as a tag. For very dynamic values, you should store as fields. Since tags could be a large string, too many series that cause high memory usage, can impact performance.

Each measurement is indexed by time and sorted. Any time-bound related query will be quite efficient. Some of the plugins might automatically create a measurement by adding very long strings, for example, server.cluster.someid.time. This will impact query performance. In such a case, consider renaming them to a shorter concise measurement name.

When writing data records into measurement, we need to check whether the time precision matches the actual dataset. For example, when dealing with market high frequency trading data, mostly it needs at least millisecond precision. But if time in measurement is second precision, some data will conflict, which may cause a loss of data and the time may be set to default 1970-01-01T00:00:00Z. On the other hand, if the data only needs second-level precision, but time in measurement is defined in nanoseconds, it will increase the size of the data on the disk, slowdown the write throughput, and timestamps may be stored as a wrong value.

In the case of a slow query, try to run show queries to list which query is slower. show queries display query ID, query text, and duration of current running queries in the current instance. Consider the following example:

> show queries;
qid query database duration
--- ----- -------- --------
10 SELECT SUM(somefield) FROM ameasurement where.. group by.. sampled 6 s

In certain cases, for very long run queries, you may want to kill it, you can run KILL QUERY. It will terminate the running query.