Is an URL a good primary key? (or what else?)

So I tried with a surrogate key, the sha1() hash of the URL. It is very useful, still long 40 chars, but it has all the problems of surrogate key: it says nothing about the data it refers to if taken by itself, and it needs some triggers and on update cascade costraints to keep the whole schema coherent if something (the url...) changes. Moreover, I need a further key on the url to speed up searches.

I want to avoid auto incremental id for the well known reasons: moreover it has to do with the data even less than the hash (i.e. nothing).

So I'm looking for and advice on it. Should I use URLs as primary key or what else? Is that performance problem on join really an issue or can I ignore it? May be because the index is already treated as an hash internally by the db?

In the meantime I'm exploring another solution. Since I'll have at least seven tables with URL as discriminant (and couting as I add features), maybe I should remove the URL from that tables and store them in another table as schema, domain, port, path, query_string, auth_user, auth_password. Then I could use the url hash on the other tables as foreign key as well as primary key. Am I totally wrong on this way?

For the sake of completeness I'm designing for MySQL 5.1, even if I'd like to avoid non-standard constructs.

Thank you in advance for any answers.