Like JPA and most other ORM's, MyBatis suffers from both the N+1 and Cartesian product problems. Consider this example of 3 tables each with 10 rows named after sequential letters of the English alphabet; ABC. Nested SELECT results in N+1 problem of 30 queries, 1 per row. Nested Results results in the Cartesian product problem of query of 1000 sets of data spread across both axis so way much data going of the wire. Now increase the number of relationships and the nested select grows exponentially with respect to number of queries and nested result grows similar but with respect to data across the wire. Like so many ORM, having the end user choose the lesser of the two evils is unacceptable on so many levels. I propose that you mimic Ebean ORM or batched implementation of GraphQL where you query in a breadth first instead of depth first manner; generationally. Root query is generation one and the end user can pass in multiple ID's like you do in MyBatis dynamic SQL. This query executes first and collect fields needed by subsequent queries which gets passed into another SELECT IN. This second generation gets collected and passed into its children relationships. The result is instead of 30 queries or 101010=1000 rows of data spread across X&Y axis you get only 3 queries one per relationship and exactly 30 units of data as one gets in the current nested select. The nested related SQL can also be customized by the end user in the MyBatis fashion allowing one to control fine tuning WHERE, ORDER BY and which fields are SELECTed. Multikey must also be supported which would allow the end user to create SQL SELECT that JOINS on the 2D array of passed in data. Instead of IN (,,,,) ... SELECT JOIN (SELECT UNION SELECT UNION SELECT) ... SELECT JOIN SELECT VALUES ((,,,), (,,,,), (,,,,,), (,,,,), (,,,,)) This ability does exist in some JPA implementations as query hints but provides no way to control SELECT WHERE and ORDER BY. EBean gives near full control but generates the SQL. MyBatis would be better since I could right SQL myself. MyBatis would further be better if it adds its existing stored procedure MARS, multiple active result set, to this feature such that all of the queries data could be retrieved by one stored procedure call. One more step beyond that is instead of a static stored procedure one that can take multiple query strings as a input parameter passed to it by my batis. Scripts for all of the major databases vendors would really smoke on the performance. https://ebean.io/docs/query/background/nplus1 https://ebean.io/docs/architecture/compare-jpa https://ebean.io/architecture/compare-hibernate SQL standard "table value constuctor" "row value constuctor" https://stackoverflow.com/questions/840254/sql-how-to-create-multi-row-results-with-no-source-table https://sinking.in/blog/pure-sql-put-if-absent-or-insert-if-not-exist/ https://decipherinfosys.wordpress.com/2008/12/26/simulating-row-value-constructor-in-versions-prior-to-sql-server-2008/