我正在使用MySQL Workbench的最新版本，但每次我尝试编写查询时，应用程序冻结最多10秒然后我可以继续写入，这不会发生在第5版。有没有办法加速MySQL Workbench 6？
答案 0 :(得分：2)
键入时等待周期的问题可能是由代码完成引起的。尝试在首选项中将其关闭，看看是否能解决您的问题。另外，请考虑打开错误报告（http://bugs.mysql.com），以便我们处理该问题。
答案 1 :(得分：1)
我刚刚从5.247（2014年1月29日）升级到版本6。它绝对无法使用。我每天写很多存储过程，而且速度非常慢。我禁用了代码完成，没有更改。
我不得不降级回旧版本。我非常失望，因为5.247有一个巨大的错误，当我编辑它时，它并不总是检测存储过程的变化。我必须重命名存储过程，然后保存，然后重新命名。
版本6修复了那个bug，但它太慢了我差点把我头上剩下的几根头发完全拉出来了。我和一位有同样问题的朋友谈过，他已经提交了一份错误报告。我希望他们能够解决这个问题，这一切都必须发生在很多人身上。它是一个很棒的数据库，我使用MySQL的问题比使用MS Sql Server时少。 - Clark Vera
答案 2 :(得分：0)
我担心Workbench在Oracle的优先级列表上并不高，这很难过，因为MySQL套件很少，并且使用TOAD for MySQL你无法进行某些迁移。
你可以尝试使用TOAD，还有Netbeans的MySQL组件（顺便说一下，这是oracle的）。
我在MySQL Workbench上乱丢了SQLServer到MySQL ETL之后就抛弃了。
答案 3 :(得分：0)
V.6.0.11834也太慢了。当我通过“帮助”菜单检查更新时，它告诉我我有最新的。它肯定在工作台内，因为查询占用的时间可以忽略不计，但是对于以下三个查询中的每一个，在结果区域中填充11个可见行（多次通过）大约需要15秒。
我在MacBook Pro Retina上使用Parallels在Windows 8上运行。
15:06:12 | select * from participant LIMIT 0,1000 | 260 row（s）返回| 0.000 sec / 0.000 sec
15:06:12 | select * from moves where participant_xid ='...'LIMIT 0,1000 | 186 row（s）返回| 0.031秒/0.016秒
15:06:17 | select * from sleeps where participant_xid ='...'LIMIT 0,1000 | 265 row（s）返回| 0.031秒/0.000秒
关闭错误列表，在那里输入...
答案 4 :(得分：0)
...我想因为上下文帮助而导致缓慢。此功能查询服务器的帮助表，以获取MySQL Workbench从当前插入符号位置派生的特定主题的帮助信息。试试这个：隐藏上下文帮助窗格（激活代码段选项卡或隐藏右侧栏）。如果看不到该上下文帮助窗格，则不会发送帮助查询。
答案 5 :(得分：0)
我有类似的问题。在我的情况下，工作台断开连接几次，结果发现我运行的进程没有正确终止。所以我使用命令行连接到我的数据库并手动终止进程。连接mysql命令后的一些有用命令：
show processlist; kill <pid> 希望这会有所帮助。