Bug #99417 MySQL Workbench: Unresponsive several minutes after each "use DB" statement
Submitted: 2 May 2020 11:13 Modified: 4 May 2020 7:47
Reporter: Danny Sevcik Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Workbench: SQL Editor Severity:S2 (Serious)
Version:8.0.19-1ubuntu18.04, 8.0.20 OS:Debian (10 Buster)
Assigned to: CPU Architecture:x86 (64bit)

[2 May 2020 11:13] Danny Sevcik
Description:
We have a project with hundreds of DB tables. Every time I open MySQL Workbench or change DB it freezes for several minutes. All points to WB executing sequentially `SHOW FULL COLUMNS FROM {DB}.{TABLE}` on each table in DB during which time one cannot execute any queries and when trying to execute more queries the UI gets unresponsive. 

It happens also every time one switches databases using navigation tree or "use DB" statement.

I sometimes cross Great Firewall of China when accessing DB and the speeds are terrible ~15kB/s which amplifies the whole issue to the point I have to abandon WB. One cannot wait 10 minutes after each `use database` statement.

----------------------------------------------------------------

More Details

When I watch process list I see 4 Workbench DB connections open. One runs bunch of SHOW FULL COLUMNS FROM {DB}.{TABLE}, another one lists processes (since I use WB's Administration/Open Connections that does work) and 2 connections sits idle.

This is the WB debug output:

21:40:27 [INF][SQL Editor Form]: Opened connection '...' to Source distribution version 5.6.21-69.0-log
21:40:28 [DB3][       GRT task]: Sending task "Live Schema Refresh Task" to dispatcher (don't wait)...
21:40:28 [DB3][  GRTDispatcher]: Running task "Live Schema Refresh Task"
21:40:29 [DB3][  GRTDispatcher]: Task "Live Schema Refresh Task" finished

-- Schema refresh started here
21:40:29 [DB3][SqlEditorSchemaTree]: Fetch schema contents for {DATABASE_HERE}
21:40:29 [DB3][       GRT task]: Sending task "Live Schema Fetch Task" to dispatcher (don't wait)...
21:40:29 [DB3][  GRTDispatcher]: Running task "Live Schema Fetch Task"

-- Here I executed query "SELECT 1;" - it started spinning wheel...
21:40:45 [DB1][SQL Editor Form]: Executing SQL in editor: SQL File 4* (current statement only: yes)...
21:40:45 [DB3][       GRT task]: Sending task "execute sql queries" to dispatcher (don't wait)...
21:40:45 [DB3][  GRTDispatcher]: Running task "execute sql queries"
21:40:45 [DB1][SQL Editor Form]: Background task for sql execution started
21:42:09 [DB2][            grt]: wb.form.showOptions finished in 67.86s

-- Schema refresh finished
21:42:36 [DB3][  GRTDispatcher]: Task "Live Schema Fetch Task" finished
21:42:36 [DB3][SQL Editor Form]: Executing statement range: 0, 8...
21:42:36 [DB3][SQL Editor Form]: Determined statement type: 8
21:42:36 [DB3][SQL Editor Form]: Result will not be editable
21:42:36 [DB3][SQL Editor Form]: Running...
21:42:37 [DB2][ SqlEditorPanel]: Query successfully finished in editor SQL File 4*
21:42:37 [DB3][  GRTDispatcher]: Task "execute sql queries" finished

-- I got result of "SELECT 1;" 2 minutes later

How to repeat:
Create 2 databases with 100 tables each and try to use (remotely to avoid superfast local responses) WB to execute query "SELECT 1".

The switch between DBs and try to repeat the query.

You will notice a long lag before results comes up.

Suggested fix:
- Make SQL execution not be blocked by simultaneously pending tables probes.

- Skip table probes altogether when "Enable code completion in editors" is OFF
[4 May 2020 7:47] MySQL Verification Team
Hello Danny Sevcik,

Thank you for the report and feedback.

regards,
Umesh
[18 Nov 2020 19:03] Vince Vaughn
I'm having the same problem on 8.0.21. I would post the build but your [redacted] 'About' interface closes everytime you click or press a key.

This is an unacceptable behavior that was not present in older versions. I am on a very fast connection that may as well be local, however the Server has over 100 databases and each database has hundreds of tables.

Waiting several minutes to run a simple query is unacceptable, and this may be the final nail in the coffin for us continuing to use MySQL. 

I'm well aware you guys don't care if I use the software or not, but this #wontfix attitude is very frustrating. Having to wait several minutes to run even a basic query can cost thousands of dollars when time is critical.

Sorry for the stern post, but seriously you guys, this can't be hard to fix or add an option to work around.
[19 Nov 2020 18:07] Dave Li
Experiencing the very same issue. We had to abandon this tool in our teams until this issue is resolved.

When it is we might reconsider getting back to but I am not quite sure, we have conservaive policy and we don't like jumping tools without serious reasons.

Looks like it was meant for small size projects, probably people running their WordPress sites. The tool is completely unusable with serious large scale projects. Sad. It had a potential and I can see that lot of work went into it already.