Perhaps another approach may work. Depending upon your application, you may want to provide a mechanism for the user to stop the process:

In your script, create a session key (incorporating the process ID and perhaps hostname of the running script, for example) and store it in a cookie. Before the "meat" of the script begins ("...writing a bunch of html files to disk created from Mysql searches..."), write out some HTML containing a button or a link which when clicked, launches a second script which uses the value in the cookie to identify the first script's process and kills it.

I realize this is not the solution you asked for. As you can see from the other responses, due to the asynchronous natture of HTTP discourse, there is no completely reliable way to detect browser disconnection.

Pressing Stop itself is not even reliable: I've seen circumstances with Internet Explorer (v5.5 SP2) where clicking Stop (or hitting Esc) had no immediate effect -- the spinning globe just kept spinning. I haven't made a study of the prevailing conditions at the time, but invariably the browser was waiting for some object or another (i.e., image or ad) to load.

Perhaps offering users an alternative to waiting might be attractive enough that they'll prefer it over simply browsing away from your results page. This approach won't prevent users from hitting Stop or browsing away from your page, but it might cut down the number of instances of it.

dmm