MySQL Bugs: #96949: Mysql Workbench takes very long time to execute the first query after connecting

Bug #96949	Mysql Workbench takes very long time to execute the first query after connecting
Submitted:	19 Sep 2019 16:20	Modified:	19 Sep 2019 16:34
Reporter:	Arun Kumar Narayanaswami	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Workbench	Severity:	S5 (Performance)
Version:	8.0.17	OS:	Linux (Ubuntu 18.04 x86_64)
Assigned to:		CPU Architecture:	Any
Tags:	WBBugReporter

Description:
----[For better reports, please attach the log file after submitting. You can find it in /home/aarayanaswami/.mysql/workbench/log/wb.log]

After opening a new MYSql connection in the workbench, the very first query takes a very long time (more than 2 mins) to execute.
All subsequent queries (in the same connection) work just fine. The issue occurs only for the first query executed after opening the connection.
Any new connection I open (in the same workbench) has the same issue for the first query executed in that connection.

Even though the query takes a long time, when it fetches the results (after about 2 mins), the Duration on the Action Output grid lists the Duration as only .07 seconds.

How to repeat:
1. Open MYSQL Workbench.
2. Open a new connection.
3. Run a query

Log

Attachment: wb.log (text/x-log), 2.43 KiB.

Thank you for the bug report. I couldn't repeat against MySQL Server 8.0.17, you are using a no supported server: Percona Server (GPL), Release 76.1.

This seems to be related to having extensive or corrupt Output History

https://stackoverflow.com/questions/1786870/mysql-slow-on-first-query-then-fast-for-relate...

Relevant Answer:
"Clear the query history! - following the process at MySql workbench query history ( last executed query / queries ) i.e. create / alter table, select, insert update queries to clear MySQL Workbench's query history really sped up the program for me.

In summary: change the Output pane to History Output, right click on a Date and select Delete All Logs.

The issue I was experiencing was "slow first query" in that it would take a few seconds to load the results even though the duration/fetch were well under 1 second. After clearing my query history, the duration/fetch times stayed the same (well under 1 second, so no DB behavior actually changed), but now the results loaded instantly rather than after a few second delay."

Bug #106810 marked as duplicate of this one.

I am having the same issue with the first query taking a long time before running.  It does not appear to be related to history as I am on a newer laptop with limited history and the issue still occurs after using "Delete All Logs".
I am only seeing this issue with MySQL Workbench (version 8.0.27 build 1228725 CE 64 bit).  I have a similar connection with Toad and there is no delay in running the query.

I have this as well where the first query after opening a connection takes minutes and then subsequent queries start executing immediately.  There is a blue spinning circle icon on the file tab from where I'm executing the query, but the "Stop the query being executed" button is not active.  So it seems it's not the query itself that is running but something else with the program. I'm also on a fresh install of MySQL Workbench after uninstalling an older version.

MySQL Workbench on Windows 10 Prod build 2235049 CE (64 bits)

Bug #111738 marked as duplicate of this one.

Bug #111887 marked as duplicate of this one.

I am experiencing the same behavior on workbench:
8.0.34 Win 10 x86

when connecting to: 

mysql-community-server-5.7.43-1.el7.x86_64 

This has become a big problem, as Workbench 6.x does not connect to this recent release of the server.

Note: clearing history does not resolve the problem.

Please test against a 5.7 server, which is listed as a supported version.

This is a repeatable bug, please update the status of the ticket.

Any update o this issue?

This is affecting me as well on Workbench 8.0.36.  It happens on a completely clean install, against a server with a large number of tables (> 10,000).  It seems to be related to loading the schema contents.  I can see on another connection via SHOW PROCESSLIST that it's running SHOW FULL COLUMNS FROM <table> against every table in the database.

The "Show Schema Contents in Schema Tree" and "Restore expanded state of the active schema objects" options are both disabled in Preferences.

I'm able to run queries immediately after opening the connection if I don't select a Default Schema in the connection settings.  If I select the Default Schema then this problem occurs.

This bug is still in v8.0.38

This bug persists in v8.0.40