In the US, in particular at least one NYC government agency, unionized "system analyst" jobs are common. They get a defined salary based on experience and level, an assigned eight hour shift with half-hour lunch break, and a clock that must be punched into on time. Another has kind and caring help desk people who nevertheless carefully watch the clock.
Here's one of my current use cases: We have a folder tree table in our (formerly nested sets, then closure table, now materialized path), and we cache a materialized version of the path with the folder names. There are some places in the app where you can look up a node by its full path, and this column should conceptually be unique. Obviously an unindexed VARCHAR(2048) is bad to filter on, but MySQL indexes can only cover the first 767 bytes (we used utf8mb4). So we have another column, PathHash CHAR(40) AS (SHA1(path)) VIRTUAL, and then a unique index on that.
I expect the idea is less to prevent any possible threat and is more a) to comply with regulations and b) to log enough data so if somebody does circumvent your legally required measures, they've left enough of a trail to hang themselves.
I was dealing with MySQL running on a Windows server box with McAfee Active Response running (MarService.exe). It has a feature for tracking files created/deleted, which is accomplished by hashing all new files, saving them to its own local DB, and presumably pushing them to the management server async. The app running on MySQL frequently creates many new tables and fills them as part of SOP, so the disk was constantly hammered by both MySQL and McAfee...
Notwithstanding the row length and column count limits, did you also give MySQL more memory? Setting InnoDB buffer pool size to 3 or 4 GB might help; its default is about 134 MB.
