The query parser is pretty much ad hoc, but it works as expected in the cases you mention. The parser generally tries to ignore errors and interpret whatever remains of the query. In your case, there are no valid conditions in the malformed query, so that the query ends up selecting all pages. The same happens for the empty query. Note that you can use "format=debug" if you want to have more information about how the query was understood without actually executing it.

One could (and probably should) disallow queries for *all* pages, but the main issue here is that such a simple query actually freezes your database. Normally, the query without conditions should be easiest to answer (given that it imposes a small limit as in your case). I think the problem here is that the SQL generation adds another instance of the smw_id table (SMW's "page table") to the query, thus enforcing a redundant inner join of potentially large tables. I have now improved the query generation process to avoid this, so the performance of the empty query should be much improved.

I have also added a new parameter "$smwgIgnoreQueryErrors" that can be used to specify if queries should be executed at all if errors occured during parsing or preprocessing. The default for this setting is "true." Together with the above, this should fix this specific bug.

There is still much room for optimising the SQL query generation. Ultimately, it might be worth to investigate the use of more specialised storage backends than MySQL (relational DBs are not particularly great for SMW's data model), or to adopt a more sophisticated table layout in SQL (especially large inner joins are an issue with the "single table" approach of SMW). I am also somewhat disappointed about the bad performance that you indicate, given that the inner join is done over the primary key of the tables: retrieving these 21 results should really be no problem in spite of the large table as such!