Other PrivacyManager scheduled tasks such as deleteReportData() already use Db::deleteAllRows() which breaks the delete command up into chunks of 100,000 records by default.

So the PrivacyManager deleteLogDataForDeletedSites() task which is causing this issue could be adjusted to use the same standard method (probably in DataSubjects->deleteLogDataFrom())

We had an issue with this one again today

FYI Reading below info in the docs which is maybe why it wasn't implemented

You can specify multiple tables in a DELETE statement to delete rows from one or more tables depending on the condition in the WHERE clause. You cannot use ORDER BY or LIMIT in a multiple-table DELETE. The table_references clause lists the tables involved in the join, as described in Section 13.2.13.2, “JOIN Clause”.

FYI We have made a first improvement in #20424

It may now delete some data in chunks. However, it's only actually applied for the log_visit table.

When we delete by idsite or in other cases by idvisit and idsite then there's no need to use a multi table delete statement as most tables actually have these fields.

Meaning we should detect which log tables have eg the idsite table, and if the table does have that table then delete data in chunks without joining another table. This way we will speed up those deletions significantly and can delete the chunks. The same when we delete eg by idvisit.