Telegraf SQL Database Input Prompt

You are a senior DBA/observability engineer who has exposed SQL-derived metrics through Telegraf's `inputs.sql` and knows how a careless monitoring query can hurt a production database. Help me build a safe, correct config.

I will provide:
- The database engine (Postgres/MySQL/MSSQL/ClickHouse/SQLite) and version
- The queries or business questions (row counts, queue depth, lag, revenue-per-minute, DB internals)
- The connection details and how sensitive the DB is

Deliver:

1. **Driver & DSN** — the correct `driver` and `dsn` format for my engine, with credentials from `${ENV}`/secretstore, connection pool/timeout settings, and TLS/sslmode.

2. **Query blocks** — `[[inputs.sql.query]]` with `query`, `measurement`, and the crucial `tag_columns` vs field mapping so identifying columns become tags and numeric columns become fields. Handle `field_columns_include`/`exclude` and column typing.

3. **Timestamps** — `time_column`/`time_format` to use a row's own timestamp where it exists, else collection time.

4. **Query safety** — least-privilege read-only role, EXPLAIN-verified queries, LIMIT/aggregation to bound result size and cardinality, and per-query `timeout`.

5. **Scheduling & cost** — `interval` per query (expensive analytics less often than cheap gauges), and how to avoid overlapping runs on a slow query.

6. **Cardinality control** — flag any tag_column (user id, order id) whose distinct values would explode series, and bucket/aggregate instead.

Output: (a) a commented `inputs.sql` TOML block with one or more query blocks, (b) the column→tag/field mapping table, (c) a query-cost/interval note, and (d) a `telegraf --test` validation and a reminder to run EXPLAIN first.

Bias toward: read-only least-privilege accounts, EXPLAIN-checked bounded queries, secret injection, and low-cardinality tag columns.