mysql - Should I split up a complex query into one to filter results and one to gather data? -

i'm designing central search function in php web application. focused around single table , each result 1 unique id out of table. unfortunately there few dozen tables related central one, of them being 1:n relations. more unfortunate, need join quite few of them. couple gather necessary data displaying results, , couple filter according search criteria.

i have been relying on single query this. has lot of joins in there and, there should 1 result displayed per id, works rather complex subqueries , group uses. gets sorted according user-set sort method , there's pagination in play done use of limit.

anyways, query has become insanely complex , while nicely build in php pita change or debug. have been considering approach, , i'm wondering how bad (or not?) performance before develop it. idea follows:

• run 1 less complex query filtering according search parameters. means less joins , can ignore group , similar constructs, "select distinct item_id" on , list of ids

• then run query, time joining in tables need display results (only 1/4 of current total joins) using ... item_id in (....), passing list of "valid" ids gathered in first query.

note: in () contain first query in full instead of relying on php build comma-separated list).

how bad in performance-wise? , how possibly hurt me can not limit first query @ all? i'm wondering if common approach or if there more intelligent ways it. i'd thankful input on :)

note clarify: we're not talking few simple joins here. there (simple) hierarchical data in there need compare search parameter against not items own data against parent's data. in no other project i've ever worked on have encountered query close complexity. , before it, yes, data has inherent complexity, why data model complex too.

my experience has shown using where in(...) approach tends slower. i'd go joins, make sure you're joining on smallest dataset possible first. reduce down simple main table, join onto that. make sure complex joins saved end minimize rows required search. try join on indexes wherever possible improve speed, , ditch wildcards in joins possible.

but agree andomar, if have time build both , measure.