There are situations when you need to update the python-paramiko library that is bundled with MySQL Workbench. This may be because you prefer
using the latest cutting edge versions, are just curious, or you can’t wait for a new Workbench version.
To update, first download the latest python-paramiko release from https://github.com/paramiko/paramiko/releases. After downloading and extracting the archive, you’ll see a paramiko folder inside of the extracted folder. This folder needs to be copied into the appropriate MySQL Workbench folder on the system.
* For Windows, this location is usually
* For OS X, this will be
* For Linux, you should use your repository manager (yum, apt-get, etc.), but if it doesn’t have the latest paramiko version then you
should first uninstall your old version, download the latest paramiko, cd into the paramiko directory, and then execute “sudo python setup.py
install” to install system wide paramiko.
Note: since Paramiko 1.12, to use it, you also need the ecdsa package which can be downloaded from here: https://github.com/warner/python-ecdsa/releases.
The same method applies; download and extract the contents of the archive, and you’ll see a ecdsa folder that should be placed next to the paramiko folder.
Please keep in mind that switching paramiko this way can break MySQL Workbench, so always make a backup first.
The schema tree in the SQL Editor now has some very convenient buttons for accessing the most used functions for each object type:
Table or Schema Inspector
Object structure editor
Table data browser/editor
Call Stored Procedure or Function
Format Note Objects in Diagrams
Note objects in diagrams can now be resized and have its contents automatically rearranged. You can also change style attributes like font, background color and text color.
Other improvements and bug fixes that make a difference
MySQL password is remembered for the session, even if not stored in the keychain, so you don’t need to re-enter it when a new connection is needed.
Keyboard shortcuts now work in the Scripting Shell.
MySQL Workbench 6.2 also finally adds native 64bit support for Windows. This should allow working with larger data sets and script files. Oracle Linux/RHEL 7 support was added. To improve quality and user experience, we will be providing 64-bit binaries for Linux. Linux users who want 32-bit binaries, can compile from source.
Include Model Scripts in Forward Engineering and Synchronization
Workbench modeling has always supported attaching SQL script files to the model, usually for documentation/organization purposes. You can now include these attachments to the output script when performing forward engineering or synchronization.
Resume data copy in Migration Wizard. If a data copy fails during database migration (because of a timeout or network failure, for example), you can now click Resume to retry the data copy. Workbench will find the last row that was copied successfully and try to restart the copy from that row.
MySQL Fabric servers can now be added to the Workbench home screen. When clicked, these connections will dynamically query the Fabric server and individual connections for all the managed MySQL servers will be created. You can then connect to each instance as usual.
Metadata Lock Browser
MySQL uses metadata locking to manage access to objects (tables, triggers, and so forth). Sometimes that can be puzzling, as your query may block waiting on an object being manipulated by another connection from maybe another user. The Client Connections list was updated to take advantage of the metadata lock information provided in the performance_schema starting in MySQL 5.7.3, to show information about what locks a connection is waiting for and what it holds.
Updated Client Connection Browser
Speaking of the Client Connection browser, a neat feature added in MySQL 5.6 is the connection attribute dictionary, which includes handy things like the name of the clients that are connected (as long as the client supports it). You can access that by clicking the Show Details button in the Client Connection screen.
In MySQL 5.7, the Optimizer Team has been doing great work in refactoring as well as innovation with the new Cost Model. The improved Visual Explain enables the DBA to now get deeper insights into Optimizer decision making, for improved performance tuning of queries. The UI was also improved to allow easier navigation in large query plans.
Streamlined Query Results Panel
The query results panel was updated to centralize the many features related to result sets into a single location. Result Grid, Form Editor, Field Types, Query Stats, Execution Plan (including the traditional and Visual Explain) and the new Spatial Viewer are all easily accessible from a single interface.
Run SQL Script
It often happens that people try to load gigantic SQL script files into the Workbench SQL editor just to execute them. That will rarely work, as loading files for editing uses a lot of memory and Workbench does a lot of processing in the editor (syntax highlighting, syntax checking, code folding etc). To execute arbitrarily large scripts easily, you can now use the dialog at File -> Run SQL Script: The dialog lets you preview a part of the script, specify a default schema (in case it’s not already defined) and a default character set to use when importing it. The output window shows warnings, messages and a nice progress bar.
SQL Snippets are useful to store queries and commands that are used often, but until now they could only be stored locally. In 6.2, you can now store snippets in the MySQL server you’re connected to and anyone anywhere who can access the .mysqlworkbench schema can also use these snippets.
Resultset grid columns are now automatically resized to fit – and if you manually resize a column, the customized size is remembered, so next time you run that query again, the columns will be back to the size you left them.
Customize font for resultset grid – some people want to cram more text in the resultset grid, some people prefer bigger, easier to read text. Now you can pick what you like in Preferences.
Improved state saving for the SQL Editor – Opened, closed and reordered tabs are now properly saved and restored. The scroll position and cursor location is also remembered.
MySQL 5.7 will include much awaited GIS support for InnoDB tables. To make it easier to quickly visualize spatial/geometry data in geographic context, Workbench 6.2 includes a viewer for resultsets containing that type of data. The viewer will render data from each row as a separate clickable element. When clicked, you can view the rest of the data from that row in the textbox. If you have multiple queries with geometry data, you can overlay them in the same map.
But that’s not all the features. The Spatial Data Viewer give you the possibility to display the data using different projection systems. Right now you can use Robinson, Mercator, Equirectangular, Bonne. There’s option to even merge different resultsets, execute all of them and switch to Spatial View, you’ll notice several layers for each resultset. You can also zoom in/out, and jump to specific location.
The Geometry Viewer
Both the Field and Form Editors were updated to support the GEOMETRY datatype. You can view geometry data like polygons from a single row as an image or as text, in any of the common WKT, GeoJSON, GML or KML formats.
MySQL Workbench has an option to view MySQL server variables divided into groups [img. 1], for example: Binlog, General, Keycache, Performance, etc. This is okay if we just wanted to look around, but it can become overwhelming as sometimes we only want to monitor specific variables from different groups.
In MySQL Workbench 6.1, we solve this by implementing Custom Groups. It’s a special group that can be created by the user. At the end of the Category List, there is already one defined group, called Custom. When selected, you’ll find a description in the Variable List [img. 2].
Variable grouping is easy. You simply right-click the chosen variable, and choose an option from the context menu.
The “Add to Custom Category…” menu item popups a mini editor that allows you to create or remove your own custom variables groups [img. 4].
You can also directly add a variable to a group by using the menu items that are located below the “Add to Custom Category…” context menu item. The groups you create will be shown in the Category list, and you only need to select them [img 5].
To remove a variable from a custom group, select the corresponding group, and then right-click to open the context menu for the variable you want to remove, and choose the remove option [img. 6].
Variables Groups are stored on the user level. In other words, each connection will have the same category groups.
We hope this new feature will help you organize your work a little bit better.
MySQL Workbench have one nice feature which is probably a stranger for some of us. The name of this feature is vertical query output, it help in situations where the standard Workbench output will not be very useful. This functionality is very easy to use and in this post I’ll try to visualize some of it’s benefits.
First we need to know how to use it, so we’ve provided you two options to execute the query with vertical output. One of them is the menu bar where you can find item named Execute vertically, you’ll also find hint about the shortcut for that option it’s CTRL+ALT+RETURN.
After you know how to get the vertical query output, I’ll show you some screen shots to compare it with command line output.
Let’s take the command that suits best to this type of output, it’s SHOW ENGINE INNODB STATUS. Normally to understand the output, you probably copy it to some notepad app, and add line breaks. Well it was a little annoying, especially when you know how does it look in command line client with \G. So let’s take a look for the output of console and Workbench.
You should find out that it’s the same view as in the console. Below you’ll see how it looks in Standard Output
and with Text Output.
Here is also one more screen shot of the EXPLAIN query:
Please fell free to comment this, and let us know how do you like it.
One of the new features of MySQL Workbench 6.0 is Table Data Search. The main purpose of this was to ease data searching through the whole instance. Previously, we needed to use some tricks to get the query to run over all schemas that we’ve got on the server. Now it’s easy to find the searched term with much less hassle. This functionality is easy to use and provides searching through all columns and even all types. However, we can’t forget that due to the nature of this tool we must take some precautions to not overload your server.
To use this functionality we pick it up from the Database menu called “Search Table Data…” or just click the icon on the main toolbar (scr 1). The third option is to select Search Table Data.. from context menu when you right click on the schema list on some schema.
After that you will see the new screen (scr 2) with a few options which you must provide to get started working with it.
As you can see, the interface is very simple, but I’ll still try to explain some of the options. The first thing is the Search for Text input, where you just put the phrase that you’d like to find. The type of the phrase depends on the select box that is located below this input (scr 3). That select box has three different options of search type which are:
Search using =
Search using LIKE
Search using REGEXP
The first one Search using =, is the simplest one, it just matches fields using the = operator.
Second option is little more powerful, it allows you to search using the database LIKE operator where you can provide wild cards like % (match any character any number of times) or _ (match any char, a single time).
The third option allows you to use regular expressions.
Next to the selection box, you’ll see two inputs described as Max. matches per table, and Max. total matches. The first one is responsible for limiting search occurrence through one table. The second one will limit the whole search, so when there will be over 10000 (initial value) entries, search will stop. Last option is the check box named Search columns of all types. Initially searching is done through only text fields, when this option is enabled, then all columns will be used and will be cast to the char data type. This check box have a great impact over whole server performance use it with caution!
Now that you know how each option relates to the searching, I’ll try to step through a sample search and describe the results. I assume that you’ve got sakila database, cause I’ll make a sample using that database.
open the Search table data…
enter text mary into the Search for Text field
check if the Search using option is set to the equal sign
check if the Search columns of all types check box is unchecked
select the schema (or column), that you’d like to be searched for the matching phrase in the schema selector
press the Start Search button.
As in the screen shot (scr 4), your result should be the same. You can click on the arrow in the result list to expand details of the row. The columns are as follows:
Schema – name of the database that holds the columns that matched the criteria Table – name of the table Key – primary key value assigned to the data that match criteria Column – column name that holds the matched data Data – the top row will contain information, how many times the phrase were matched in the details it will contains the matched data
There is also context menu for the result set, it’s available when you right click on the result set. The menu allows you to copy query that where used to find the matching rows. you can also copy query that will match the rows against primary key, and the last option allows to copy the key values.
And that’s all, you’ve done your first search using the new Search Table Data option. Please remember that using this feature have very big impact on general server performance because you’re generally doing full table scans. Stay with us to get more information cool information.