This is a known issue, and something I'm leaving for future releases. The attributes are not stored in the same table but rather stored vertically in the attribute_values table. This is an efficient storage method for an unlimited number of attributes, but is not so efficient for simple retrieval and sorting tasks. Since sorting cannot be done at the database end, and instead needs to happen after retrieval by the scripts. I want to investigate different methods of managing this.

I guess a query like the following could be used. It does the sorting and the pagination in a single SQL query (example with 2 attributes only):

select p.*, a1.value as 'attr1', a2.value as 'attr2'
from lime_participants p
left join lime_participant_attribute a1 on (a1.participant_id=p.participant_id and a1.attribute_id=1)
left join lime_participant_attribute a2 on (a2.participant_id=p.participant_id and a2.attribute_id=2)
order by a1.value
limit 0,25

Of course the list of attributes (names and ids) has to be fetched beforehand in a separate query in order to build the list of columns to select (and tables to join with).

Hope it can give you ideas...

Awesome, thanks @lolo - since the sorting is only ever done by one column - we could just do one join like this for the column being sorted and keep collecting the remainder of the data the other way. :-)

Glad to be helpful.
By applying these techniques you could have it all -attributes names and values- in one or two queries instead of n, which will scale better with large amounts of data.
As the saying goes "if you torture SQL long enough, it will confess" ;)

Fixed it in another bug that i related so marking the original that I missed as duplicate. Searching is still to be fixed, but there is another bug open for that.

The fixes are not released yet so if you want to test, please check out the latest source on github. Feel free to reopen or comment on the other bugreport (6956).