MySQL SELECT Query – How to Match String with User Input

Some RDBMS (SQL Server) allow you to get this information easily. Especially for a direct DB connection from code running in the user's session on Windows, using Windows Auth to connect to SQL Server.

It can be done if the user connects to a website, which then connects to SQL Server too.

However, you're on MySQL.

Your simplest option is to have the client code send it in, derived from the OS. Ypu can then pass this in to the trigger as per this SO answer https://stackoverflow.com/questions/324605/mysql-trigger-storing-a-select-in-a-variable

I would have put it in a comment but do not have enough reputation to do so...
So here some advice I find useful when looking for performance issues like these. Use the -- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - to check if your system in healthy, if you can improve parameter, do it first, since it will allow you to better test other options.
The entries in the slow_log help you but they can be misleading, e.g. when a connection explicitly or implicitly locks tables. I have seen it many times that the statements showing up in the slow_log are the victims, not the culprits.
You already got a very valuable suggestion with switching to InnoDB, MyISAM tables are notorious for locking the whole table for changes, mostly blocking the whole table on any update with default settings.
There is however one database engine that has even worse locking than MyISAM and most people will not ever assume it: the memory table engine (HEAP)
If a memory table is very active, and you are running low on memory, I have seen ungodly high waiting/lock waiting times on these. If your are very daring you can mount a tempfs directory in your MySQL database directory and create a temporary InnoDB database/table, otherwise a regular InnoDB with a somewhat more relaxed write policy will do the trick as well. Regular memory tables do not allow for the use of indexes which sometimes leads to very bad optimization of complex queries involving them.
To narrow down what is really causing the queries to wait for a lock, or better to find out what is locking them, you can use SHOW PROCESSLIST or the nice mytop tool. The processes with the highest time values are you most likely culprits. It is also noteworthy that you might find processes that are running way longer than long_query_time but will never show up in your slowlog, because they consist of multiple statements, all of which may execute fast enough one by one...
If you see a number of processes piling up in mytop, you should investigate the list carefully, since this is an easy way of finding the culprit!
If locking is introduced trough transactions (implicit or explicit) you can try to optimize the performance by changing your transaction isolation level with [SET TRANSACTION][2]. One has to be careful with this since thses changes sometimes tend to break (poorly written) applications, or better said applications that rely on a certain behaviour.
So if your locked tables on SELECT statements are locked by design, because someone misused the database as a glorified process lock (I have seen that before) it might break that intended behaviour at the same time as fixing your performance issue... good luck!