Preface: I would not use this in a production environment on a full time basis. When we do use it, we turn it on, gather some logs and turn it off. Also, it has been pointed out to me that this will cause MySQL to not use the query cache in versions previous to 5.0. That is another reason to not use this in a production environment full time.
So, on dealnews.com we often end up with a lot of queries that look kind of the same. It usually because we have a complex query that simply selects article ids from one or two tables and then a second query to select the data from the article table using those ids. If you have used MySQL much, you know that is often the better solution than doing a join where one table is huge and you need to order by the smaller table.
However, this becomes a problem when you start having a problem with a query or two. You can't tell from a mysqladmin proc where the query is coming from. So, I came up with a solution.
We use a class that I wrote for all of our access to mysql. Its basically a wrapper for mysql_connect, mysql_select_db, mysql_query, mysql_num_rows(), etc. One method to handle all of that. Lots of you probably have one of these objects or libraries. Anyhow, what I did was add a comment into the sql just before I run the query:
if(!empty($_SERVER["REQUEST_URI"])){
$uri = str_replace("*/", "%2A/", $_SERVER["REQUEST_URI"]);
$SQL = "/* $uri */\n$SQL";
} else {
$uri = str_replace("*/", "%2A/", $_SERVER["SCRIPT_FILENAME"]);
$SQL = "/* $uri */\n$SQL";
}Now, mysqladmin proc has the request URI for every query in it. The MySQL slow query log does as well. I know this is a simple little thing, but man, is it useful.
Ed Says:
You should be careful using this -- on some older (and not too much older) versions of MySQL putting a comment before SELECT caused it to bypass the query cache.
e.g.
SELECT cols from table -- can use the query cache
/* http://mysite.com/ */ SELECT cols from table -- cannot use the query cache (on some versions)