MySQL storage-benchmark target — measure view materialisation performance

[58bits]

Named follow-up from Section 5 of the MySQL adapter design spec: build a MySQL counterpart to the existing Postgres storage-benchmark sweep so the adapter's view-materialisation performance is measured rather than assumed.

This is useful performance-characterisation work, not a blocker for MySQL general availability. The GA criteria are tracked separately in #58.

Spec: specs/2026-07-24-db-mysql-adapter-design.md, Section 5 ("out of scope (named follow-ups)") and Risk 1 ("View materialisation performance").

Why this is worth measuring

Both current-version views (byline_current_documents, byline_current_published_documents) resolve the current version per document via a ROW_NUMBER() OVER (PARTITION BY document_id) window inside a derived table in the view's FROM clause — the same shape the Postgres adapter uses, and the same construct the Postgres benchmark sweep identified as the one place storage cost scales with collection size (see docs/03-architecture/01-document-storage.md, "current_documents is the one place that scales with collection size").

Whether MySQL's query planner and InnoDB's storage engine handle that window-inside-a-derived-table shape with the same cost profile Postgres does is an open, measurable question. It is worth characterising so future performance work is driven by evidence, but the complete shared conformance suite already establishes the adapter's functional correctness independently of these measurements.

Scope

• Reuse or port the existing benchmark harness (benchmarks/storage/harness/) against @byline/db-mysql at the same scale points as the latest Postgres sweep (10k / 50k / 100k documents) — see the 2026-07-21 sweep for the comparison baseline and query shapes to reproduce.
• Report cold-path latency for the same query set: single-document reads (full and selective), list-view pagination, field filter + sort, batch fetch, populate.
• If list-view latency shows the same or worse scaling as the Postgres current_documents join cost, decide whether the same mitigation (defer the documents join until after LIMIT, or materialise the view as a table) applies identically to MySQL or needs its own adapter-specific approach.

This issue can be scheduled and resolved independently of MySQL GA.