WooCommerce Database Optimization: MySQL/InnoDB Indexing & Query-Tuning für maximale Performance

1) Datenbank-Baseline erstellen (Messpunkte statt Bauchgefühl)

1.1 Relevante WooCommerce-Tabellen und typische Hotspots

Für Performance-Probleme in WooCommerce sind meist nicht „die Datenbank“ allgemein schuld, sondern konkrete Zugriffsmuster: häufige Reads auf Produkt-/Variationsdaten, order-lastige Writes und teure Meta-Abfragen. Typische Hotspots in MySQL (InnoDB) sind:

• wp_posts / wp_postmeta: Produkte (posts) und Metadaten (postmeta), Variationen, Lager, Preise
• wp_options: Autoload-Bloat bremst jede Request-Initialisierung
• wp_woocommerce_order_items / wp_woocommerce_order_itemmeta: Orders, Positionen, Metadaten
• wp_wc_order_stats / wp_wc_product_meta_lookup (falls aktiv): Lookup-Tabellen für schnellere Aggregationen

1.2 InnoDB/MySQL: Kurz-Check der Engine-Realität

WooCommerce läuft praktisch immer auf InnoDB. Das heißt: Indizes sind B-Tree, Writes erzeugen Redo/Undo, und fehlende/ineffiziente Indizes führen zu vielen Random I/Os und Lock-Contention. Daher: erst messen, dann indexieren/tunen.

2) Query Optimization: Langsame Abfragen finden und verstehen

2.1 Slow Query Log und EXPLAIN als Pflichtwerkzeug

Aktiviere (temporär) das Slow Query Log auf MySQL und analysiere anschließend die teuersten Queries. Für jede auffällige Query ist EXPLAIN (bzw. EXPLAIN ANALYZE ab MySQL 8) der schnellste Weg zu sehen, ob Indizes genutzt werden, ob Full Table Scans passieren und wie groß die geschätzten/realen Rows sind.

Ziel: Reduce scanned rows, avoid filesort/temp tables, ensure selective indexes on join/filter columns.

2.2 Typische WooCommerce-Antipatterns

• Meta-Queries auf wp_postmeta ohne selektive Indizes: z. B. Filter nach Preis/Lager als Meta-Werte → führt oft zu Scans und Sortierungen.
• Autoload-Overload in wp_options: große/zu viele autoloaded Optionen verlangsamen jede Seitenanfrage.
• Order-Auswertungen auf Live-Tabellen: Reporting über wp_posts + postmeta statt Lookup/Stats-Tabellen.

3) Indexing Strategies (InnoDB): Indizes gezielt für WooCommerce setzen

3.1 Prinzipien guter Index-Strategien

• Index nur für reale Query-Muster: Indizes beschleunigen Reads, kosten aber Write-Performance und Speicher.
• Composite Index Reihenfolge: linkspräfixe Regel – setze zuerst die Spalte mit hoher Selektivität, die im WHERE immer vorkommt.
• Covering Index: wenn möglich, so dass MySQL Daten aus dem Index lesen kann, ohne Table Lookup.
• Vermeide „Index-Spam“: zu viele Indizes auf wp_postmeta/order_itemmeta können Writes massiv bremsen.

3.2 WooCommerce-spezifische Index-Kandidaten (bewusst prüfen!)

Die folgenden Ideen sind häufig sinnvoll, müssen aber anhand eurer Slow-Queries validiert werden:

• wp_options: Index auf (autoload) existiert oft nicht; sinnvoller ist eher Autoload zu reduzieren. Ein zusätzlicher Index kann helfen, wenn ihr häufig nach autoload='yes' selektiert und die Tabelle groß ist.
• wp_postmeta: Abfragen wie meta_key + meta_value profitieren von Composite Indizes, aber Vorsicht: meta_value ist LONGTEXT; hier braucht es Prefix-Indizes oder alternative Strukturen (Lookup-Tabellen).
• wp_woocommerce_order_itemmeta: häufige Filter auf meta_key und Join über order_item_id → Composite Index kann helfen.

4) Automatisierte Analyse: Python Script for Database Analysis

Das Script verbindet sich zu MySQL, sammelt Tabellen-Größen, Index-Infos und erkennt typische WordPress/WooCommerce-Problemstellen (z. B. große wp_options Autoload-Summe, Meta-Tabellenwachstum). Ergebnis: eine kompakte, umsetzbare Übersicht.

Python Script for Database Analysis

import os
import json
import math
from dataclasses import dataclass
from typing import Dict, List, Tuple

import mysql.connector


@dataclass
class TableInfo:
    name: str
    rows: int
    data_mb: float
    index_mb: float
    total_mb: float


def mb(x: int) -> float:
    return round(x / 1024 / 1024, 2)


def get_conn():
    return mysql.connector.connect(
        host=os.environ.get("DB_HOST", "127.0.0.1"),
        port=int(os.environ.get("DB_PORT", "3306")),
        user=os.environ.get("DB_USER", "root"),
        password=os.environ.get("DB_PASSWORD", ""),
        database=os.environ.get("DB_NAME", "wordpress"),
    )


def fetchall_dict(cur) -> List[Dict]:
    cols = [c[0] for c in cur.description]
    return [dict(zip(cols, row)) for row in cur.fetchall()]


def table_sizes(cur, schema: str) -> List[TableInfo]:
    cur.execute(
        """
        SELECT
          table_name AS name,
          table_rows AS rows,
          data_length AS data_length,
          index_length AS index_length
        FROM information_schema.tables
        WHERE table_schema = %s
        ORDER BY (data_length + index_length) DESC
        """,
        (schema,),
    )
    out = []
    for r in fetchall_dict(cur):
        total = int(r["data_length"] or 0) + int(r["index_length"] or 0)
        out.append(
            TableInfo(
                name=r["name"],
                rows=int(r["rows"] or 0),
                data_mb=mb(int(r["data_length"] or 0)),
                index_mb=mb(int(r["index_length"] or 0)),
                total_mb=mb(total),
            )
        )
    return out


def indexes_for_table(cur, schema: str, table: str) -> List[Dict]:
    cur.execute(
        """
        SELECT
          index_name,
          non_unique,
          seq_in_index,
          column_name,
          sub_part,
          index_type,
          cardinality
        FROM information_schema.statistics
        WHERE table_schema = %s AND table_name = %s
        ORDER BY index_name, seq_in_index
        """,
        (schema, table),
    )
    return fetchall_dict(cur)


def autoload_options_size(cur, wp_prefix: str) -> Dict:
    # Approximates autoload payload size
    sql = f"""
        SELECT
          COUNT(*) AS autoload_count,
          SUM(CHAR_LENGTH(option_value)) AS autoload_bytes
        FROM {wp_prefix}options
        WHERE autoload = 'yes'
    """
    cur.execute(sql)
    r = fetchall_dict(cur)[0]
    bytes_ = int(r["autoload_bytes"] or 0)
    return {
        "autoload_count": int(r["autoload_count"] or 0),
        "autoload_mb": round(bytes_ / 1024 / 1024, 2),
    }


def meta_table_growth(cur, wp_prefix: str) -> Dict[str, Dict]:
    tables = [
        f"{wp_prefix}postmeta",
        f"{wp_prefix}woocommerce_order_itemmeta",
        f"{wp_prefix}termmeta",
        f"{wp_prefix}usermeta",
    ]

    result = {}
    for t in tables:
        try:
            cur.execute(f"SELECT COUNT(*) AS cnt FROM {t}")
            cnt = int(fetchall_dict(cur)[0]["cnt"])
            result[t] = {"rows": cnt}
        except mysql.connector.Error as e:
            result[t] = {"error": str(e)}
    return result


def main():
    schema = os.environ.get("DB_NAME", "wordpress")
    wp_prefix = os.environ.get("WP_PREFIX", "wp_")

    conn = get_conn()
    try:
        cur = conn.cursor()

        sizes = table_sizes(cur, schema)
        top10 = sizes[:10]

        autoload = autoload_options_size(cur, wp_prefix)
        meta_growth = meta_table_growth(cur, wp_prefix)

        # pull index summary for common Woo tables
        interesting = [
            f"{wp_prefix}posts",
            f"{wp_prefix}postmeta",
            f"{wp_prefix}options",
            f"{wp_prefix}woocommerce_order_items",
            f"{wp_prefix}woocommerce_order_itemmeta",
        ]

        idx = {}
        for t in interesting:
            table = t.replace(wp_prefix, "")
            try:
                idx[t] = indexes_for_table(cur, schema, t)
            except mysql.connector.Error:
                # some installs use different prefixes / missing tables
                idx[t] = []

        report = {
            "schema": schema,
            "top_tables_by_size": [t.__dict__ for t in top10],
            "autoload_options": autoload,
            "meta_tables": meta_growth,
            "indexes": idx,
            "notes": [
                "If autoload_mb is high (e.g. > 2-5 MB), reduce autoloaded options before adding indexes.",
                "Use slow query log + EXPLAIN to justify any new indexes (InnoDB write amplification).",
            ],
        }

        print(json.dumps(report, indent=2))

    finally:
        conn.close()


if __name__ == "__main__":
    main()

5) WP-CLI-Workflow: Aufräumen + wiederholbare Maintenance (Bash Script)

WP-CLI ist ideal, um wiederkehrende Aufgaben (Transients, Revisions, Cron) standardisiert auszuführen. Das reduziert Ballast in MySQL und verbessert Cache-Warmup sowie Admin-Performance. Das Script unten ist bewusst defensiv: Es prüft Voraussetzungen, erstellt optional ein Backup und loggt Ergebnisse.

Bash Script for WP-CLI Commands

#!/usr/bin/env bash
set -euo pipefail

WP_PATH="${WP_PATH:-/var/www/html}"
WP_BIN="${WP_BIN:-wp}"
DATE_STR="$(date +%F-%H%M%S)"
LOG_FILE="${LOG_FILE:-/tmp/wpcli-db-maint-${DATE_STR}.log}"
DO_DB_EXPORT="${DO_DB_EXPORT:-1}"

cd "$WP_PATH"

echo "[INFO] Starting WP-CLI maintenance at $(date -Is)" | tee -a "$LOG_FILE"

if ! command -v "$WP_BIN" >/dev/null 2>&1; then
  echo "[ERROR] wp binary not found. Set WP_BIN or install WP-CLI." | tee -a "$LOG_FILE"
  exit 1
fi

# Verify WordPress context
"$WP_BIN" core is-installed --quiet || {
  echo "[ERROR] WordPress not installed / wrong path: $WP_PATH" | tee -a "$LOG_FILE"
  exit 1
}

if [[ "$DO_DB_EXPORT" == "1" ]]; then
  echo "[INFO] Exporting DB..." | tee -a "$LOG_FILE"
  "$WP_BIN" db export "/tmp/wp-db-backup-${DATE_STR}.sql" --quiet
  echo "[INFO] DB export saved to /tmp/wp-db-backup-${DATE_STR}.sql" | tee -a "$LOG_FILE"
fi

echo "[INFO] Cleaning transients..." | tee -a "$LOG_FILE"
"$WP_BIN" transient delete --all | tee -a "$LOG_FILE"

echo "[INFO] Cleaning post revisions..." | tee -a "$LOG_FILE"
"$WP_BIN" post delete $("$WP_BIN" post list --post_type='revision' --format=ids) --force 2>/dev/null || true

echo "[INFO] Optimizing database tables..." | tee -a "$LOG_FILE"
"$WP_BIN" db optimize | tee -a "$LOG_FILE"

echo "[INFO] Checking cron events (top 20)..." | tee -a "$LOG_FILE"
"$WP_BIN" cron event list --fields=hook,next_run_relative,recurrence --format=table | head -n 25 | tee -a "$LOG_FILE"

echo "[INFO] Done at $(date -Is)" | tee -a "$LOG_FILE"

6) Deployment-Ready Checks als YAML (Runbook/CI Job)

Damit Optimierung kein einmaliges „DB-Feng-Shui“ bleibt, lohnt sich ein wiederholbarer Runbook-Job (z. B. in CI oder als Ops-Playbook). Beispiel: YAML-Runbook mit klaren Schritten für Analyse (Python) und Maintenance (WP-CLI via Bash).

runbook:
  name: woocommerce-database-optimization
  prerequisites:
    - mysql_access: true
    - wp_cli_available: true
    - maintenance_window: recommended
  env:
    DB_HOST: 127.0.0.1
    DB_PORT: 3306
    DB_NAME: wordpress
    DB_USER: wp_user
    DB_PASSWORD: "${DB_PASSWORD}"
    WP_PREFIX: wp_
    WP_PATH: /var/www/html
  steps:
    - id: baseline_analysis
      description: "Collect table sizes, index inventory, autoload size, meta table counts"
      command: "python3 scripts/db_analysis.py > /tmp/db-report.json"
      artifacts:
        - /tmp/db-report.json
    - id: wpcli_maintenance
      description: "Cleanup transients/revisions + db optimize (creates optional db export)"
      command: "bash scripts/wpcli_maintenance.sh"
    - id: verify_after
      description: "Re-run analysis to confirm deltas"
      command: "python3 scripts/db_analysis.py > /tmp/db-report-after.json"
      artifacts:
        - /tmp/db-report-after.json
  acceptance_criteria:
    - "autoload_options.autoload_mb reduced or stable under agreed threshold"
    - "no increase in slow queries after change"
    - "checkout and product listing TTFB improved in synthetic test"

7) Entscheidungslogik: Wann Indizes vs. Strukturänderungen?

flowchart TD
  A[Slow queries detected] --> B{Query uses WHERE/JOIN on indexed columns?}
  B -- Yes --> C[Check cardinality + rows scanned via EXPLAIN]
  C --> D{Still scanning too many rows?}
  D -- Yes --> E[Add/adjust composite index for WHERE+JOIN order]
  D -- No --> F[Optimize query shape: reduce meta queries, avoid SELECT *]
  B -- No --> G[Design index strategy: add selective index]
  G --> H{Column type suitable for indexing?}
  H -- No (LONGTEXT/meta_value) --> I[Use lookup tables / denormalize / WC product meta lookup]
  H -- Yes --> E
  E --> J[Validate: EXPLAIN ANALYZE + slow log delta]
  F --> J
  I --> J

8) Praktische Empfehlungen (WooCommerce-Realität)

• Autoload zuerst entschlacken: bevor ihr „mehr Indizes“ setzt, reduziert autoload in wp_options (Plugin-Leichen, große Serialized Arrays).
• Produktfilter nicht über freie Meta-Queries skalieren: nutzt WooCommerce Lookup-Tabellen/integrierte Strukturen, statt Preis/Lager dauerhaft aus postmeta zu filtern.
• Orders wachsen → Writes werden dominant: bei hohen Order-Raten Indizes sehr gezielt setzen und Reports entkoppeln (z. B. Stats/ETL).
• Immer mit EXPLAIN belegen: jede Index-Änderung ist eine Hypothese, die ihr messt (InnoDB Write Amplification).

9) Umsetzung mit externer Unterstützung

Wenn ihr das als dauerhaftes Performance-Programm aufsetzen wollt (Monitoring, Query-Review, Index-Change-Management, WP-CLI Runbooks), kann eine spezialisierte WooCommerce Agentur die Maßnahmen sauber testen und release-sicher ausrollen.