← R2 SQL / r2-sql

Průvodce řešením potíží

Tento návod popisuje možné chyby a omezení, se kterými se můžete setkat při používání R2 SQL. R2 SQL je ve fázi otevřené beta verze a podporovaná funkčnost se postupem času bude vyvíjet a měnit.

Problém: R2 SQL vyžaduje FROM klauzuli ve vašem dotazu.

-- Invalid - Missing FROM clause
SELECT user_id WHERE status = 200;

-- Valid
SELECT user_id
FROM my_namespace.http_requests
WHERE status = 200 AND timestamp BETWEEN '2025-09-24T01:00:00Z' AND '2025-09-25T01:00:00Z';

Řešení: Vždy uveďte FROM s plně kvalifikovaným názvem tabulky (namespace_name.table_name).

Příznak: Dotaz vrátí chybu 502 Bad Gateway nebo vyprší časový limit.

Problém: Vícenásobná spojení napříč velkými tabulkami mohou překročit limity zdrojů, zejména s COUNT(DISTINCT) nebo jiných agregací náročných na paměť.

-- May timeout: cross-joining two large fact tables
SELECT COUNT(DISTINCT h.ray_id), COUNT(DISTINCT f.event_id)
FROM my_namespace.http_requests h
INNER JOIN my_namespace.firewall_events f ON h.zone_id = f.zone_id

Řešení:

• Přidejte WHERE filtry, abyste zmenšili velikost mezivýsledků.
• Spojujte přes dimenzní tabulky, ne přímým spojením faktových tabulek.
• Použijte approx_distinct() místo COUNT(DISTINCT) pro přibližné počty.
• Rozdělte složitá vícenásobná spojení na menší dotazy pomocí CTE nebo posloupnosti dotazů.

-- Better: filter both sides and use approx_distinct
SELECT z.plan,
       approx_distinct(h.ray_id) AS unique_requests
FROM my_namespace.zones z
INNER JOIN my_namespace.http_requests h ON z.zone_id = h.zone_id
WHERE z.plan = 'enterprise'
  AND h.status_code >= 400
GROUP BY z.plan

Příznak: NOT IN poddotaz vrací neočekávané výsledky nebo chyby.

Problém: NOT IN poddotazy nejsou podporovány, pokud sloupec poddotazu může obsahovat NULL hodnoty.

-- Fails: nullable_col may contain NULLs
SELECT zone_id
FROM my_namespace.http_requests
WHERE zone_id NOT IN (
    SELECT nullable_col FROM my_namespace.other_table
)
LIMIT 20

Řešení: Použijte NOT EXISTS s korelovaným poddotazem.

-- Works: NOT EXISTS handles NULLs correctly
SELECT h.zone_id
FROM my_namespace.http_requests h
WHERE NOT EXISTS (
    SELECT 1 FROM my_namespace.other_table o
    WHERE o.nullable_col = h.zone_id
)
LIMIT 20

Příznak: EXISTS nebo NOT EXISTS poddotaz běží pomalu.

Problém: Korelované poddotazy se složitými podmínkami mohou být pomalé, protože se vnitřní dotaz vyhodnocuje pro každý řádek vnějšího dotazu.

-- Slower: multiple filter conditions in correlated subquery
SELECT z.domain
FROM my_namespace.zones z
WHERE EXISTS (
    SELECT 1 FROM my_namespace.firewall_events f
    WHERE f.zone_id = z.zone_id
      AND f.risk_score > 0.9
      AND f.colo = 'SJC'
)
LIMIT 20

Řešení:

• Kde je to možné, zjednodušte korelované podmínky.
• Zvažte přepsání na JOIN hodnotou GROUP BY místo EXISTS.
• Použijte IN poddotaz s předagregovanými výsledky místo EXISTS.

Problém: Funkce JSON zatím nejsou implementovány. Pole uvnitř objektů JSON nelze filtrovat pomocí operátorů JSON path.

-- Invalid - JSON path operators not supported
SELECT * FROM my_namespace.requests WHERE json_data->>'level' = 'error'

-- Valid - Filter on the entire JSON column
SELECT * FROM my_namespace.logs WHERE json_data IS NOT NULL LIMIT 100

Řešení:

• Denormalizujte často dotazovaná pole JSON do samostatných sloupců.
• Filtrujte podle celého pole JSON a parsování řešte ve vlastní aplikaci.

Problém: Hodnoty LIMIT musí být mezi 1 a 10,000.

-- Invalid - Out of range
SELECT * FROM my_namespace.events LIMIT 50000

-- Valid
SELECT * FROM my_namespace.events LIMIT 10000

Řešení: Používejte hodnoty LIMIT mezi 1 a 10,000.

Problém: OFFSET není podporován.

-- Invalid - Pagination not supported
SELECT * FROM my_namespace.events LIMIT 100 OFFSET 200

-- Valid - Use cursor-based pagination with ORDER BY and WHERE
-- Page 1
SELECT * FROM my_namespace.events
WHERE timestamp >= '2024-01-01'
ORDER BY timestamp
LIMIT 100

-- Page 2 - Use the last timestamp from the previous page
SELECT * FROM my_namespace.events
WHERE timestamp > '2024-01-01T10:30:00Z'
ORDER BY timestamp
LIMIT 100

Řešení: Implementujte stránkování založené na kurzoru pomocí ORDER BY a WHERE podmínek.

Problém: R2 SQL je dotazovací engine pouze pro čtení. Příkazy DDL a DML nejsou podporovány.

-- Invalid - Schema changes not supported
ALTER TABLE my_namespace.events ADD COLUMN new_field STRING
UPDATE my_namespace.events SET status = 200 WHERE user_id = '123'
CREATE TABLE my_namespace.test (id INT)
DROP TABLE my_namespace.events

Řešení: Spravujte schéma prostřednictvím pipeline pro příjem dat a R2 Data Catalog.

Pokud vaše dotazy běží pomalu:

1. Vždy zahrňte filtry podle oddílu (timestamp): Toto je nejdůležitější optimalizace.

   -- Good - Narrows data scan to one day
   SELECT * FROM my_namespace.events
   WHERE timestamp BETWEEN '2024-01-01' AND '2024-01-02'
   LIMIT 100

2. Použijte selektivní filtrování: Zahrňte konkrétní podmínky, abyste omezili velikost výsledných sad.

   -- Good - Multiple filters reduce scanned data
   SELECT * FROM my_namespace.events
   WHERE status = 200 AND region = 'US' AND timestamp > '2024-01-01'
   LIMIT 100

3. Výběr konkrétních sloupců: Vyhněte se SELECT * pokud potřebujete jen několik polí.

   -- Good - Only reads the columns you need
   SELECT user_id, status, timestamp
   FROM my_namespace.events
   WHERE timestamp > '2024-01-01'
   LIMIT 100

4. Prováděcí plán zkontrolujte pomocí EXPLAIN: Ověřte, že predicate pushdown a file pruning fungují.

   EXPLAIN SELECT user_id, status
   FROM my_namespace.events
   WHERE timestamp > '2024-01-01' AND status = 200

5. Povolte komprimaci: Povolte kompaktaci v R2 Data Catalog, abyste snížili počet malých souborů prohledávaných při každém dotazu.