You don't need to MySQL-escape identifiers unless you are using a reserved word, such as date. It's your choice, but you'd save yourself some typing and will improve readability.
First off, I'd changing all uppercase letters in identifiers since MySQL is case insensitive on some platforms and case sensitive on others. If you stick with camel-casing, leading capitals or similar, you risk up having code that breaks if you ever move to another MySQL platform.
I'd also recommend changing Pays to pays_id INT UNSIGNED and add a FOREIGN KEY(pays_id) REFERENCES pays(id), as well as creating a separate table pays with id and name (and possibly country code) to normalize your schema, thus avoiding storing redundant data and removing the risk of erroneus changes in the future (where half the country names are changed and half are left unchanged).
As for your actual question, are you certain those towns really are duplicates? I'm not talking about the names, but rather the towns as such. You may have two towns with the same names in different countries, or even in the same country.
But, looking at your table structure, you are most likely correct, due to a similar issues as you had with duplicate country names. I.e. the same town name existing several times for the same town; once per postal/zip code of that town.
Once again, the solution is to remove the postal code into its own table, consisting of postal_code and town_id. Or possible postal_code_start, postal_code_end and town_id, to define a range or ranges of postal codes for a town.
Server has gone away is probably due to lack of proper indexing which means your query takes way too long time. Your SQL statement looks correct to me, even though you'd most likely want to add t1.CP != t2.CP. Or to avoid the extrem case low risk scenario of two countries having a town each with the same name and postal code, AND t1.CP != t2.CP AND t1.Pays != t2.Pays. So try adding indices for all fields used as constraints in the where clause. I.e. Ville, CP (and Pays if you include that part in your query). I'm not sure if KEY is a shorthand notation for PRIMARY KEY, but unless you allready know what KEY means, check your db reference to see if it implies an index (as primary key does). Otherwise you should change it to primary key. Well, assuming cp_id is actually unique, since your table isn't normalized.
