Reduce impact of scan for a db large tables

[GarethSpace48]

uses a query to generate a query to run an RLIKE on all fields in the table, so that you only get rows return with encrypted values (and not every row), thus reducing the memory impact

[VladyslavSikailo]

worked for me in the same way as the original solution ✅

[vitaliy-golomoziy]

In a new version we got rid of fetchAll and scanning the whole database record by record (see #7). I'm afraid that for large tables, a series of RLIKE queries might be very slow and introduce an extra load on the database (like querying search terms, or something like that). We would like to minimise the impact of the scan operation on a live environment (assuming that the script can be executed on a separate/cron/admin instance and won't impact production operations).
The proposed solution is interesting, we may incorporate it as an algorithm of choice, something like --algorithm=php or --algorithm=sql.

Do you have any measurements on time/memory/cpu of a php-based version versus sql-based?

It would be very interesting to see such measurements.

[GarethSpace48]

Hey, sorry, been a wild couple of weeks @vitaliy-golomoziy

I didn't have any metrics, I can put some together though if you want.

I did spot a problem with this, I couldn't use the SQL in this PR on one of the clients because of an different MySQL version (I haven't gone back and worked out why, but for that client I ran the version without fetchAll)