I have a MySQL database containing a table with a binary-typed column. I'd like to be able to project that column without having to run it through, e.g., HEX()
. Does the mysql
CLI tool have a configuration option or other means to display a representation of binary data in a manner that won't output arbitrary bytes for my console to interpret in hilarious/annoying ways?

- 12,401
- 6
- 41
- 50
-
What is wrong with `HEX()`? It seems the perfect solution. – wallyk Mar 23 '12 at 16:04
-
7Because having to do that when all I really want is a quick `SELECT * ...` is fairly inconvenient. – Richard Simões Mar 23 '12 at 16:55
5 Answers
Set mysql client options in /etc/my.cnf
works for me:
[client]
binary-as-hex = true
[mysql]
binary-as-hex = true

- 1,734
- 19
- 16
-
1This config breaks mysqldump (version 5.7): `mysqldump: [ERROR] unknown variable 'binary-as-hex=true'` – Sergey Shambir Jul 09 '21 at 12:45
-
It's enough to use [mysql] binary-as-hex = true and this will not break mysqldump – Alex Sep 11 '21 at 06:59
-
This does not works with mysql 5.5, could you specify from which version this has been introduced? Where can the doc with the possible option could be found? – MUY Belgium May 17 '23 at 12:58
-
Since you want to look at the table mostly for convenience, create a view:
CREATE OR REPLACE VIEW myview AS
SELECT col1, HEX(col2) AS col2, col3, etc....
FROM table;
Then, all you have to do is reference myview
instead of table
:
SELECT * FROM myview;

- 56,922
- 16
- 83
- 148
The behavior of the MySQL command line client when viewing result sets with binary data has always been an annoyance to me, in fact I found this page because I was once again annoyed by the MySQL command line client (dumping binary data into my terminal when looking at a result set with binary UUID columns) and I wanted to solve the issue once and for all :-)
Creating views really isn't an option for me (I'm looking at dozens of tables with binary UUID columns) and I also found that it's really annoying to switch from SELECT *
to typing out all of the column names instead (just so HEX()
can be applied to the value of one column).
Eventually I came up with a creative hack that provides inspiration for alternative solutions to this annoyance: Using a custom pager command to sanitize output for terminal rendering. Here's how it works:
Create an executable (chmod +x) Python script with the following contents:
#!/usr/bin/python import binascii, string, sys for line in sys.stdin: line = line.rstrip() column, _, value = line.partition(': ') if any(c not in string.printable for c in value): sys.stdout.write("%s: %s\n" % (column, binascii.hexlify(value))) else: sys.stdout.write("%s\n" % line)
Start the MySQL command line client as follows:
$ mysql --pager=/home/peter/binary-filter.py --vertical ...
Change the pathname of the Python script as applicable. You can also put the script in your
$PATH
, in that case you can just pass the name to the--pager
option (similar to how you would useless
as a pager for the MySQL client).Now when you
SELECT ...
, any line that shows a column whose value contains non-printable characters is rewritten so that the complete value is rendered as hexadecimal characters, similar to the results of MySQL'sHEX()
function.
Disclaimer: This is far from a complete solution, for example the Python snippet I showed expects SELECT ... \G
format output (hence the --vertical
option) and I tested it for all of five minutes so it's bound to contain bugs.
My point was to show that the problem can be solved on the side of the MySQL command line client, because that's where the problem is! (this is why it feels backwards for me to define server side views - only to make a command line client more user friendly :-P)

- 4,888
- 3
- 24
- 15
For me there is no problem with database size, so I will use two different column in every table, one as binary(16), and the second as char(32) without indexing. both of them will have the same value. when I need to search I will use binary column, and when I need to read I will use char(32). is there any problem with this scenario?

- 345
- 2
- 13