MySQL and SQLite - regular expressions in the predicate

Regular expressions can provide you with an invaluable service when used wisely in SQL queries.
They can save you from having to sort through the cursor cycles, or (oh, horror!) In the cycles of the basic application language, solid chunks of tables. The truth is sometimes the service can be "bearish."
Examples and features of the use of this technique

For example, we have business-logic applications, in which at the first stage the user can create an arbitrary record in the database, and at the second stage use this arbitrary record as a foreign key.
The task is quite predictable - it is required to observe the uniqueness of the record.
I can offer to consider such a solution (yes, it is not universal, because I supplement an arbitrary user record, thereby formally changing it. On the other hand, quoting Clarkson: "Yes, I am a tyrant! Do you want democracy - go to Iraq!" ) :
DDL tables

CREATE TABLE `human_link` (
`translit_link` varchar (255) NOT NULL DEFAULT 'main' ,
`owner` int NOT NULL ,
PRIMARY KEY (`translit_link`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

* This source code was highlighted with Source Code Highlighter .

Where the arbitrary entry under discussion is the `translit_link` field, which, to maintain the uniqueness, we supplement with the digit (1) or, if there is already a digit, increase the digit by +1.
You can find out if there is a similar entry by request.

SELECT `translit_link` FROM `foo`.`human_link`
WHERE `translit_link` REGEXP CONCAT( '^' ,?, '[[:digit:]]*$' ) ORDER BY `translit_link` DESC LIMIT 1;

* This source code was highlighted with Source Code Highlighter .

Actually, it remains only to figure out what has returned to us and to do with the return what the logic of preserving the uniqueness of the field tells us (an example of this technique that comes closer to life, using perl and the stored procedure - read my blog).
But it was all just a saying.
The tale is this - EXPLAIN MySql about this query will say Using where; Using index Using where; Using index , but when using SQLite from DBD :: SQLite -

REGEXP function
It would be quite costly in terms of performance.

In addition, not everything is so smooth in MySQL either - in the book “High performance MySQL: optimization, backups, replication, and load balancing” By Jeremy D. Zawodny, Derek J. Balling, there is a line that expressions like WHERE last_name RLIKE ”(son | ith) $ "will be unrealistically slow for reasons that can be explained, but an expression of the type WHERE rev_last_name RLIKE" ^ (thi | nos) "will be slower than two WHERE-union unions for" thi% "and" nos% "because MySQL the optimizer never tries to optimize a regular expression based query . ”
From which we conclude that not all yogurts are equally useful.

Ps. I would be very grateful for the hint how things are in PostgreSQL, Oracle and in the MS camp. :)
Pps. I am aware of the existence of ON DUPLICATE KEY UPDATE - the procedure behaves incorrectly when using a composite unique index (multiple unique indexes). Those. IMHO, theoretically, it is generally unsafe for business logic, because imposes implicit restrictions on created indexes.