Mit der folgenden SQL Abfrage können Sie die 20 größten Tabellen inklusive Daten, Index und Gesamtgröße anzeigen:

SELECT
    TABLE_NAME AS Tabelle,
    TABLE_ROWS AS Zeilen,
    ROUND(DATA_LENGTH / 1024 / 1024, 2) AS Daten_MB,
    ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS Index_MB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS Gesamt_MB,
    ROUND(DATA_LENGTH / 1024 / 1024 / 1024, 3) AS Daten_GB,
    ROUND(INDEX_LENGTH / 1024 / 1024 / 1024, 3) AS Index_GB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 3) AS Gesamt_GB
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'MAGENTO_DATENBANK'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

MAGENTO_DATENBANK muss dabei durch den tatsächlichen Namen der Magento Datenbank ersetzt werden. Dieser steht beispielsweise in app/etc/env.php unter dbname.

Interessant sind vor allem Gesamt_MB beziehungsweise Gesamt_GB, da hier Daten und Indizes zusammengezählt werden. So fällt schnell auf, wenn beispielsweise eine Cron, Quote, Log oder Extension Tabelle ungewöhnlich viel Platz belegt.

Die Spalte Zeilen sollte bei InnoDB nur als ungefährer Wert betrachtet werden. Für die Suche nach besonders großen Tabellen sind dagegen DATA_LENGTH und INDEX_LENGTH entscheidend.

Die Abfrage verändert keine Daten und eignet sich deshalb gut als erster Überblick, bevor genauer untersucht wird, warum eine Magento Datenbank so groß geworden ist.

Magento 2 bringt dafür bereits ein eigenes Query Log mit. Es lässt sich direkt über die CLI aktivieren:

bin/magento dev:query-log:enable

Die protokollierten Datenbankabfragen landen anschließend in var/debug/db.log und können beispielsweise live verfolgt werden:

tail -f var/debug/db.log

Interessanter wird die Ausgabe, wenn nicht jede kleine Abfrage protokolliert werden soll. Magento kann gezielt nur Queries erfassen, die länger als einen bestimmten Wert benötigen:

bin/magento dev:query-log:enable \
--include-all-queries=false \
--query-time-threshold=0.5 \
--include-call-stack=true

Damit werden in diesem Beispiel nur Datenbankabfragen ab 0,5 Sekunden protokolliert. Durch include-call-stack wird zusätzlich der Aufrufpfad ausgegeben, wodurch sich häufig erkennen lässt, welches Modul oder welcher Code die Abfrage ausgelöst hat.

Gerade bei langsamen Produktseiten, Importen, Cronjobs oder individuellen Extensions lässt sich damit schnell herausfinden, ob eine einzelne Query zum Flaschenhals wird.

Nach der Analyse sollte das Query Log unbedingt wieder deaktiviert werden:

bin/magento dev:query-log:disable

Besonders mit aktiviertem Call Stack kann die Logdatei sonst schnell anwachsen.

Die folgende SQL Abfrage liefert Ihnen genau diese Produkte ohne Produktbilder:

SELECT
    p.entity_id,
    p.sku,
    p.type_id
FROM catalog_product_entity AS p
LEFT JOIN catalog_product_entity_media_gallery_value_to_entity AS mg
    ON mg.entity_id = p.entity_id
WHERE mg.value_id IS NULL
ORDER BY p.entity_id;

Ausführung auf eigene Gefahr. Bitte auf einem Testsystem prüfen oder mindestens ein Backup der Datenbank anfertigen vor dem Ausführen!

DELETE FROM sales_order WHERE ... ;
DELETE FROM sales_order_grid WHERE ... ;

Löschen Sie nun den Magento 2 Cache und überprüfen Sie, ob die Bestellungen wie gewünscht gelöscht wurden.

Die Lösung ist denkbar einfach. Führen Sie die folgenden SQL Queries aus und das Problem ist gelöst:

SET FOREIGN_KEY_CHECKS=0;
UPDATE core_store_group SET group_id = 0 WHERE name = 'Default';
UPDATE core_store SET store_id = 0 WHERE code = 'admin';
UPDATE core_website SET website_id = 0 WHERE code = 'admin';
UPDATE customer_group SET customer_group_id = 0 WHERE customer_group_code = 'NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;

DELETE FROM catalog_product_entity;

Durch die Contraints dieser Tabelle werden Produktverbindungen auch sauber aus anderen Tabellen entfernt.

SELECT
  *
FROM catalog_product_entity
WHERE entity_id NOT IN (SELECT DISTINCT
    product_id
  FROM catalog_product_option);

Wenn Sie alle Produkte suchen, die individuelle Optionen haben, entfernen Sie einfach das “NOT” aus der obigen Abfrage.

UPDATE `admin_user` SET `password` = MD5('NEUESPASSWORT') WHERE `username` = 'ADMINUSERNAME';

SELECT
  *
FROM eav_attribute
WHERE (
`attribute_id` LIKE '%stomlayoutupdate%'
OR `entity_type_id` LIKE '%stomlayoutupdate%'
OR `attribute_code` LIKE '%stomlayoutupdate%'
OR `attribute_model` LIKE '%stomlayoutupdate%'
OR `backend_model` LIKE '%stomlayoutupdate%'
OR `backend_type` LIKE '%stomlayoutupdate%'
OR `backend_table` LIKE '%stomlayoutupdate%'
OR `frontend_model` LIKE '%stomlayoutupdate%'
OR `frontend_input` LIKE '%stomlayoutupdate%'
OR `frontend_label` LIKE '%stomlayoutupdate%'
OR `frontend_class` LIKE '%stomlayoutupdate%'
OR `source_model` LIKE '%stomlayoutupdate%'
OR `is_required` LIKE '%stomlayoutupdate%'
OR `is_user_defined` LIKE '%stomlayoutupdate%'
OR `default_value` LIKE '%stomlayoutupdate%'
OR `is_unique` LIKE '%stomlayoutupdate%'
OR `note` LIKE '%stomlayoutupdate%'
);

Notieren Sie sich die attribute_ids aus dem Ergebnis und führen Sie danach diese Abfrage aus:

DELETE
  FROM eav_attribute
WHERE attribute_id IN (attribute_ids aus erster Abfrage);

Fertig!

SELECT
  cpe.sku,
  q.product_status
FROM catalog_product_entity cpe
  JOIN (SELECT
    entity_id AS product_id,
    value AS product_status
  FROM catalog_product_entity_int
  WHERE entity_type_id = (SELECT
    entity_type_id
  FROM eav_entity_type
  WHERE entity_type_code = 'catalog_product')
  AND attribute_id = (SELECT
    attribute_id
  FROM eav_attribute
  WHERE attribute_code = 'status'
  AND entity_type_id = (SELECT
    entity_type_id
  FROM eav_entity_type
  WHERE entity_type_code = 'catalog_product'))) q
    ON cpe.entity_id = q.product_id;

Status 1: aktiviert
Status 2: deaktivert