The following SQL query lists the 20 largest tables, including data size, index size and total size:

SELECT
    TABLE_NAME AS Table_Name,
    TABLE_ROWS AS Rows_Estimated,
    ROUND(DATA_LENGTH / 1024 / 1024, 2) AS Data_MB,
    ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS Index_MB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS Total_MB,
    ROUND(DATA_LENGTH / 1024 / 1024 / 1024, 3) AS Data_GB,
    ROUND(INDEX_LENGTH / 1024 / 1024 / 1024, 3) AS Index_GB,
    ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024 / 1024, 3) AS Total_GB
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'YOUR_MAGENTO_DATABASE'
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC
LIMIT 20;

YOUR_MAGENTO_DATABASE Replace this with the actual name of your Magento database. You can find it, for example, in app/etc/env.php under dbname.

The Total_MB and Total_GB are particularly useful because it includes data and indexes. This helps spot unusually large cron, quote, log or extension tables.

The column Rows_Estimated should be treated only as an approximate value for InnoDB. For locating especially large tables, DATA_LENGTH and INDEX_LENGTH are more important.

The query does not change any data and is a useful first check before investigating why your Magento database has grown so large.

Magento 2 includes a Query Log that you can enable directly from the CLI:

bin/magento dev:query-log:enable

Recorded queries are written to var/debug/db.log and can be followed live with:

tail -f var/debug/db.log

If you do not want to log every small query, Magento can also record only those above a given duration:

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

In this example, only database queries taking at least 0.5 seconds are logged. The include-call-stack option also records the call stack, helping you identify which module or code triggered a slow query.

Especially for slow product pages, imports, cron jobs and custom extensions, this can reveal whether one database query is the bottleneck.

Disable the query log again after your analysis:

bin/magento dev:query-log:disable

With call stack logging enabled, the file may otherwise grow very quickly.

The following SQL query returns products without product images:

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;

Proceed at your own risk. Test on a staging system or at least make a complete database backup first!

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

Clear the Magento 2 cache afterwards and verify that the intended orders were removed.

The solution is straightforward. Run the following SQL queries to resolve the issue:

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;

Due to the constraints it will delete all related data from other tables as well.

DELETE FROM catalog_product_entity;

Thanks to the constraints on this table, product relationships are also removed from the relevant tables.

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

To get all products that do have custom options, remove the “NOT” from the above query.

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

To find all products that do have custom options, simply remove “NOT” from the query above.

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