優化分析查詢
1）為什麼要優化（iGaming上下文）
業務速度：p95 SLA中的GGR/NET報告，提供商/遊戲，RG/AML和營銷。
成本：掃描字節和藏紅花較少→低於$/請求。
可靠性：穩定高峰時段,沒有BI「凍結」。
規模：數十個品牌/市場，數十億行，新鮮分鐘。
2）負載配置文件和SLO
描述「前90%」查詢：窗口（7/28/90d）,過濾器（「品牌,國家/地區,provider, psp, status」）,join's, JSON屬性,top K和percentili。
SLO示例：p95 ≤ 1。2 s用於dashboard，掃描字節≤ 256 MV/查詢，freshness ≤ 5 min。
3）計劃解剖學： 尋找什麼
Predicate/Projection pushdown：過濾器和列列表降到源。
Partition pruning&data skipping：切斷多余的部分/文件（min-max/bloom/manifest）。
Vectorized scan/late materialization：通過JOIN/PROJECT延遲的列讀取。
Join strategy: Broadcast Hash (BHJ), Sort-Merge (SMJ), Nested Loop (NLJ — избегать).
Spill&shuffle：洗牌體積和海峽到磁盤是SLA的主要敵人。
Adaptive query execution：在rantime中更改策略（切換BHJ↔SMJ、動態聯盟）。
計劃必須顯示：讀取多少字節，藏紅花在哪裏，我們緩存什麼。
4）分期、排序、群集案例
批次：通過「日期」+1-2訪問度量（例如「品牌，國家」）。
分類/聚類："ORDER BY/CLUSTER BY/Z-order"（"provider, game_id, occurred_at')。
回收和堆積：用於數據跳板的常規橫桿；目標文件大小128-1024 MB。
5）JOIN模式
Broadcast Hash Join （BHJ）：小維度（≤ 數百MB） →廣播到事實。
sql
/ hint if engine supports/
SELECT /+ BROADCAST(dim_provider) /...Sort-Merge Join （SMJ）：大型集、兼容的關鍵排序/群集案例→最小的收縮。
預加成/非規範化：將穩定屬性從「dim_」推導到事實快照（projection/materialized view）-減去關鍵路徑上的JOIN。
Anti/semijoins：將「NOT IN/EXISTS」重寫為顯式的semi -/anti-joins計劃。
消除基本爆炸：檢查測量中的重復密鑰,使用surrogate-keys。
6） GROUP BY、聚合和預聚合
Rollup/Cube/Grouping Sets：一個階段而不是多個聚合。
sql
SELECT brand, country, DATE(ts) d, SUM(amount)
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
GROUP BY GROUPING SETS ((brand,country,d),(brand,d),(d));實例化視圖（MV）/投影：「payments_7d_by_brand_psp」，「rounds_1d_by_provider_game」。
Partial → Final aggregation：讓引擎部分聚合在竊聽器上（本地）,最後聚合在協調員上。
Approximate： HLL for 「COUNT （DISTINCT user）」, TDigest for percentiles-價格便宜兩倍,足以滿足BI的需求。
7）窗口功能（整齊）
PARTITION BY恰好是高選擇性的密鑰；ORDER BY-通過柱狀排序。
在可能的情況下用預裝和半裝配替換重型窗口。
sql
-- Instead of window distinct
SELECT brand, COUNT() users
FROM (SELECT DISTINCT brand, user_id FROM gold. sessions WHERE d>=CURRENT_DATE-7) t
GROUP BY brand;8）過濾器、分頁和TOP-K
濾波器的順序對於CBO並不重要，但是選擇性和索引/排序很重要。
LIMIT …WITH TIES/APPROX TOP-K-縮短掃描。
分區：「keyset pagination」而不是「OFFSET/LIMIT」用於大表。
sql
-- keyset
SELECT FROM t WHERE (date, id) > (:last_date,:last_id) ORDER BY date, id LIMIT 1000;9） JSON/半結構化
將熱路實現到揚聲器（'device.os`, `psp.method`).
如果引擎支持,則在JSON 路徑上使用反向索引/GIN。
通過行避免UDF：使用屬性突出顯示更好地投影。
10）Approx和Sampling
HLL/Theta素描：便宜的「COUNT DISTINCT」。
TDigest/KLL：p95/p99無滿分。
Reservoir/stratified采樣：交互式研究和預覽。
11）記憶，海峽和卡倫西
拼寫後衛：join/agg上的內存限制；海峽-減少擊球/並行主義，增加按鍵排序。
Concurrency＆QoS：用於「熱」dashbords和重型hoc的池；掃描/時間限制；kill-switch到「被遺忘」的請求。
Result cache/query cache：啟用可重復的BI模式,在新鮮度令牌上致殘。
12）回歸測試和「雙重運行」
存儲前N查詢的參考配置文件（計劃/掃描字節/時間）。
在發布索引/群集之前-A/B運行：比較p95、scanned bytes、skipped share, shuffle。
創建「fail-fast」閾值：如果p95增長了>X%-回滾。
13）可觀察性和SLO
SLI:
p50/p95/p99 latency, scanned bytes/query, skipped bytes %, files touched;
shuffle bytes, spilled bytes, peak memory;
cache hit-rate;accuracy approx聚合體。
Alerts： scanned bytes的增長,skipped share的下降,頻繁的NLJ,海峽>門檻.
14） iGaming Case（食譜）
14.1 付款/PSP：「故障高峰」
WHERE: `ts BETWEEN now()-7d AND now()`, `brand,country,psp,status`.
聚會： 日；ORDER/Z-order: `(brand,country,ts)`;bitmap: `psp,status`;bloom: `transaction_id`.
MV: `payments_7d_by_brand_psp(status)`.
底線：p95 → ~ 1 s，掃描字節↓ 5-10 ×，零海峽。
14.2場比賽回合：前K場比賽/小時
ORDER BY / cluster по `(provider, game_id, occurred_at)`;預聚合的投影。
Approx Top-K+TDigest用於p95回合持續時間。
底線：熱緩存上的子秒圖形。
14.3 RG/AML：活動限制
JSON 「reason」 →專欄；bitmap `rg_state`, `kyc_level`;semi-join與最新狀態。
底線：「30天」報告-秒，沒有全掃描。
15）優化支票清單（每日）
1.收集前N查詢及其配置文件（計劃/字節/shafl）。
2.按日期分組+商定排序/群集案例。
3.檢查推送和投影運行（僅限所需列）。
4.JOIN策略：廣播小，SMJ排序，沒有NLJ。
5.熱達什板的預聚合/MV。
6.Approx在允許的地方（distinct/percentiles/top-k）。
7.JSON →列和/或反向索引。
8.復合/復構化；skipped bytes目標≥ 70%。
9.結果緩存和單獨的concarrency池。
10.監視：p95，scanned bytes，shuffle，spill，hit-rate。
16）模板（準備使用）
16.1優化策略（YAML）
yaml workload: bi_hot slo:
p95_latency_ms: 1200 scanned_bytes_max_mb: 256 skipped_bytes_share_min: 0. 70 storage:
partition_by: ["date"]
cluster_by: ["brand","country","occurred_at"]
indexes:
bloom: ["transaction_id","user_surrogate_id"]
bitmap: ["psp","status","rg_state"]
aggregation:
mv:
- name: mv_payments_7d_brand_psp window: "7d"
group_by: ["brand","psp","status"]
approx:
count_distinct: "hll"
percentile: "tdigest"
concurrency:
pools: {bi_hot: 50, adhoc: 10}
timeout_s: 12016.2查詢回歸測試（偽SQL）
sql
-- baseline: p95<=1200ms, scanned_bytes<=256MB
EXPLAIN ANALYZE
SELECT brand, psp, status, COUNT() cnt, SUM(amount) amt
FROM gold. payments
WHERE ts >= NOW() - INTERVAL '7 days'
AND brand =:brand AND country =:country
GROUP BY brand, psp, status;16.3 DISTINCT重寫
sql
-- Bad: Heavy COUNT (DISTINCT user_id)
SELECT COUNT(DISTINCT user_id) FROM gold. sessions WHERE d>=CURRENT_DATE-7;
-- Better: HLL sketch/preaggregate
SELECT hll_union(user_hll) FROM agg. sessions_7d_user_hll WHERE d>=CURRENT_DATE-7;16.4 Keyset分離
sql
SELECT
FROM gold. game_rounds
WHERE (occurred_at, round_id) > (:ts,:rid)
AND brand=:brand AND country=:country
ORDER BY occurred_at, round_id
LIMIT 1000;17）反模式
銷售中的「SELECT」；沒有投影啟動。
數百萬行上的OFFSET分頁。
COUNT DISTINCT沒有草圖；穿過一個完整的sort。
大型裝置上的NLJ；在JSON表達式上加入。
小批次和分散的文件（元數據風暴）。
WHERE中的UDF字符串代替了專欄的實現。
忽略統計學家/ANALYZE-盲目優化器和全掃描。
沒有回歸測試和回滾閾值。
18）實施路線圖
0-30天（MVP）
1.測量前N查詢並安裝SLO/SLI。
2.按日期+排序/群集案例分組；啟用data skipping/bloom。
3.每「熱門」支付報告一個MV；HLL/TDigest в BI.
4.分離查詢池,啟用結果緩存。
30-90天
1.重型窗口普查/JSON →預聚合/列。
2.小維廣播合作；大型的SMJ；消除NLJ。
3.按計劃進行堆疊和重新排列；密鑰自動交換機。
4.可觀察性和降解異同，A/B計劃，自動回滾。
3-6個月
1.具有轉換和SLA 的投影/MV目錄。
2.Distinct/percentile/top-k的內核Approx跨所有行車記錄板。
3.統一回歸測試和預算$/請求模板。
4.JSON和UDF持續衛生：物化與指數。
19) RACI
數據平臺（R）：分期/聚類/復合、MV/投影、緩存、監控。
Analytics/BI （R）：重寫SQL、approx聚合、回歸測試。
域所有者（C）：切割和精度要求。
安全/DPO（A/R）：隱私/PII，單元的k匿名。
SRE/Observability（C）：SLO/Alerting，Concarrency和Capasity。
財務（C）：$/查詢預算和經濟影響。
20）相關部分
分析存儲索引，數據模式及其演變，數據驗證，DataOps實踐，數據聚類，維數降低，分析和度量API，MLOps：模型操作。
底線
查詢優化不是「魔術印記」，而是系統：可讀的數據標記（批次/集群），預聚合和預置算法，正確的JOIN策略，緩存/串聯以及持續監視p95和掃描字節。對於iGaming來說，這意味著在SLA和預算範圍內快速穩定的支付、遊戲和合規指標。