Description:
Selecting all 108888 rows of a table with 23 columns (MyISAM, data length 30379752) from a local mysqld takes about 15s in Workbench and about 3s in Query Browser. Using the vertical scrollbar I only get about 2 screen refreshes per second, whereas Query Browser follows the mouse movements directly.

You could argue that scrolling through such a dataset doesn't show accurate information and that I should use additional clauses in my select statements, but I like doing this to get a quick visual impression of data quality or data distribution (to be able to modify the query with said additional clauses to get hard facts) and it is certainly more accurate than only looking at the first 1000 rows. This is perfectly supported in Query Browser, but not doable in Workbench.

How to repeat:
See above.

Could you please provide the output of Help->System Info. Thanks in advance.

MySQL Workbench CE for Windows version 5.2.25
Data Directory: C:\Programme\MySQL\MySQL Workbench 5.2 CE
Cairo Version: 1.8.8
Rendering Mode: OpenGL is available on this system, so OpenGL is used for rendering.
OpenGL Driver Version: 2.0.5148 WinXP Release
OS: Microsoft Windows XP Professional Service Pack 3 (build 2600)
CPU: 2x Intel(R) Pentium(R) D CPU 2.80GHz, 3.5 GiB RAM
Video adapter info:
Adapter type: 128MB ATI RADEON X600 SE
Chip Type: RADEON X600 SE (0x5B62)
BIOS String: 113-A26044-108
Video Memory: 131072 KB

How long will MySQL CLI need for the select?

You need to stop time from fire the SELECT command until all rows are displayed.

Maybe this is confusing you.

Because one tool starts displaying directly when it found the first hit and the other first select all and then displays them.

Yes, I know about this difference (which is another win for Query Browser...) and measured the time accordingly. Query Browser starts displaying data (and counting "rows fetched") nearly instantly, only if there is an old result set it takes roughly a second to empty the list beforehand.

Workbench takes about a second for switching output tabs etc. when I only select the first 1000 rows (the default). Query Browser is ready with its work just the moment my finger leaves the Enter key, even with 3000 rows.

selecting to stdout with the command line client is very slow under windows, because the cmd windows are slow, output redirection to NUL is much slower than piping into a program either.

mysql --port=3306 --batch --quick --raw --user=u --password=p -e "select * from table" db | perl -ne "1"

takes about 3 seconds, that includes the connection overhead and starting the two programs and piping the data.

Please try 6.0.2

Fixed as of the MySQL Workbench 6.0.2 release, and here's the changelog entry:

MySQL Workbench suffered from slow performance when selecting a large amount
of data, such as 100,000+ rows.

Thank you for the bug report.

Sorry, but output is still notably slower.

I have a new machine now, and I am selection the first 1000000 rows from an InnoDB table (11 columns, average row length 154).

It says "Fetching..." and the first data row appears after about 24 seconds, at the same time the message "Fetching..." changes to "1000000 row(s) returned" and under "Duration / Fetch" it says "0.016 sec / 7.628 sec".
When I drag the scroll bar handle with the mouse, scrolling fells a bit sluggish, when I scroll around at the top of the list, about 6-8 updated per second.
At the bottom of the list I only get about 1 (one) update per second, this is really slow. The list implementation gets slower when you scroll down, but isn't interactively fast anyway.

With Query Browser the first rows appear the moment my finger leaves the enter key. There appear more rows in the until after 9 seconds all 1000000 are shown and the message is "1000000 Zeiles in 7,9993 s (0,0038 s) geholt". When I drag the scroll bar handle with the mouse, the result table scrolls as fast as I can move the mouse, the feedback is very direct.

Can you try something? In one of these queries that take 24s to execute, add '' in the list of select fields. For example, instead of select * from table, do a select *, '' from table.

Does that make it faster?

Maybe I should have made it clearer, but there is no query involved that takes 24s to execute. The query executes faster -- it is MySQL Workbench which took 24s to display the first rows of the result and which is unbearibly slow when scrolling the list.

No, neither the query nor MySQL Workbench get faster with the extra column:

3	4	11:39:29	SELECT * FROM <mytable>
 limit 1000000	1000000 row(s) returned	0.016 sec / 4.071 sec
3	5	11:40:32	SELECT *, '' FROM <mytable>
 limit 1000000	1000000 row(s) returned	0.015 sec / 4.025 sec

In both cases the result appeared after approx. 20 seconds.

As (in production but especially in development) queries may be slow to generate rows, it is extremely counter-productive that MySQL Workbench always stores the complete result before displaying anything. Sometimes the result rows just trickle in and you want to see that and not be forced to kill the query and experiment with different LIMITs. This behaviour is ok for a 'how to show query results in your own programs' tutorial, but it is not ok for a serious tool. MySQL Workbench does not only that, but it takes much longer than MySQL Query Browser to display the complete result as well.

I modified a large file viewer (implemented with perl and the Wx GUI-Library):

- the data is presented in a virtual List View (Wx::ListCtrl with flags wxLC_REPORT|wxLC_VIRTUAL), the data is not completely filled into the table, but the ListCtrl object asks for the data it just needs for drawing itself
- the data is read from the database connection (DBI) and serialized into an indexed file, in parallel
- the ListCtrl polls the file repeatedly to get the current number of rows; until the query has ended.

I see the first rows after a fraction of a second. The result list is scrollable the whole time without lag. The complete result arrives after about 7 seconds.

I don't even need a default LIMIT in my queries. You could store the result in memory up to a given size and only then 'swap out' to disk. Or just use memory.

If I can do it -- in perl -- a big company like Oracle will be able to handle big query results also.

I'm setting this to verified. The request is to make the result viewer more responsive, not necessarily faster.

Marking as duplicate of bug #72946 to unify bugs