The query, as written, takes 90K * 100K (9G!) operations.
To assist in analyzing slow SELECTs, please provide
* SHOW CREATE TABLE tbl\G -- engine, indexes
* SHOW TABLE STATUS LIKE 'tbl'\G -- sizes
* EXPLAIN SELECT ...\G -- clues of inefficiencies
* SHOW VARIABLES LIKE '%buffer%'; -- cache size
and surround them with [ code ] and [ / code ]
Then we can discuss whether (and how much) changes to INDEXes and the query itself will help.
Multi-table update may work better than the subquery.
Are the IP-ranges overlapping? If so, you have an ambiguity problem. If not, we may be able to take advantage of the fact.
IPv6 is coming soon...
http://forums.mysql.com/read.php?10,293341,293341
Is the first table dense? That is, are there any gaps? (Or can you fix that table so there are no gaps.) With such, SELECT ... WHERE ip >= fromip LIMIT 1 is guaranteed to get the 'right' row without worrying about toip. Instead of actually doing that, I might use a UNION trick to create a 190K (90+100) tmp table, index it, do a self join, and finally do a multi-table update. This might be under 1M operations (much better than 9G).