Add covering indexes on the 1000G LD tables (tkg_p3v5a_ld_*) for LD lookups

[boxiangliu]

Owner: @gaojunbin — this is DDL on the shared locuscompare2 DB, so route it through schema-change-coordination (ADR-0008), not a unilateral change.

What

The regional-plot backend (#25) colors variants by LD r² to a lead, via:

SELECT SNP_B, R2 FROM tkg_p3v5a_ld_chr{N}_{POP} WHERE SNP_A = 'rs...'
UNION ALL
SELECT SNP_A, R2 FROM tkg_p3v5a_ld_chr{N}_{POP} WHERE SNP_B = 'rs...'

Two covering indexes make each call two short range scans:

• (SNP_A, SNP_B, R2)
• (SNP_B, SNP_A, R2)
  (115 tables: chr1–22,X × AFR/AMR/EAS/EUR/SAS.)

Priority: LOW / nice-to-have

Measured live: an LD lookup on tkg_p3v5a_ld_chr17_EUR already runs in ~0.2s without any added index — so this is a hardening/perf item, not a blocker. Worth doing before we serve heavy traffic; not urgent for the MVP.

Coordination checklist (per the process doc)

• Confirm current indexes on a sample LD table (SHOW INDEX FROM tkg_p3v5a_ld_chr17_EUR).
• Estimate size/time to add across 115 tables; run off-peak.
• Confirm no impact to locuscompare2's own queries.

[boxiangliu]

Measured — recommend parking this. Checked tkg_p3v5a_ld_chr17_EUR (22.7M rows) live:

• It already has single-column indexes on SNP_A and SNP_B.
• EXPLAIN for our lookup: type=ref, key=SNP_A, rows examined = 73 (not 22.7M). That's why it's ~0.2s.

A covering index (SNP_A, SNP_B, R2) would only remove the ~73 secondary row look-ups per query (index-only scan) — a negligible shave on an already sub-second query, at the cost of a wide 3-column index over 22.7M rows × 115 tables (tens of GB of shared-DB storage). Not worth it. Reopen only if profiling shows LD lookups are a real bottleneck.