That’s a known problem with WordPress and searches involving postmeta.
What I’d try to do is to create a new taxonomy for “things” you’re usually searching the most:
offer_order_statusseems the better candidate, as it can be active or not. I’d create a taxonomy with two elements. That would reduce the time of your search considerably- If that is not enough, the next step I’d probably try is to define “buckets” for the other two “meta” you’re using and create taxonomies for them: area and price. Buckets can be created in to different ways: you could have a “size” taxonomy that was
> 100000, another one> 200000, etc, and then for prices, you may want to do< 100000,> 100000 && < 200000. That really depends on how you plan to search.
The whole point for step two is that you can hook into the save action of the post to “read” what is the area/size for that property, and then pick the right taxonomies for it and add them automatically in the backend. By doing that, you get the benefit of:
a) having the taxonomies always in sync with the actual meta value (you don’t want to have people adding “the same” or similar information more than once).
b) you can change the “buckets” of the taxonomies at any time to fullfill your “new” needs: as you have the real value for those fields, you’ll just need to “save” again all posts to get the right taxonomies (and you can do that programatically).
c) taxonomy-based search is muuuuuuuch faster than meta search (is an indexed&relatively small table, compared to postmeta)
A second approach, that won’t work that well for this case, but is still an option, is to add indexes to the postmeta table, indexing by post_id, meta_key and meta_value. That will also speed up the query, by using indexes, but probably not that much.
But as it’s much easier to implement than the previous one, I’d probably try to implement this second option first and see how it goes.