Fixing mysqltuner ERROR 1054 on Ubuntu Server 16.04

It was only last March that here at work we’ve updated our machines to Ubuntu 16.04 LTS, just a month before the 2018 edition of the server-ready realease of the Linux distribution that has come to be de ‘de-facto’ standard for Bioinformatics.

I am running mysqltuner to see how the server can be most finely tuned. Unfortunately the package still has problems (ie. in two years the updated version has not been back ported) so I am facing the mysqltuner ERROR 1054 on Ubuntu Server 16.04.

Here’s how I solved it, after a quick digging’ on my search engine:

cd /opt
git clone
cd MySQLTuner-perl
sudo mv /usr/bin/mysqltuner /usr/bin/mysqltuner.bak
sudo ln -s /opt/MySQLTuner-perl/ /usr/bin/mysqltuner

Then I’ve successfully ran my script. Enjoy!

via →

Published by kOoLiNuS

♂, Italian, male, husband, dad of a wonder, “cazzaro”, friendly, blogger, motorcyclist, geek, avid reader, sysadmin, ICT consultant, curious. I come in peace… I'm an active social networker since 1999. I've been using WordPress sice 2004 and since 2006, and I'm currently involved in WordPress and WooCommerce communities in Bari, Apulia.

Join the Conversation


  1. I’ve run MySQLTuner on Ubuntu 16.04 with no issues. My issues is in understanding the recommendations. There is little guidance as to where to find and adjust the items that need adjusting.


    1. Was it a clean install or an upgraded one? In my case this server was born like an Ubuntu 12.04 and has been upgraded since then…


      1. My server was a clean install. I have not had good luck with Ubuntu updates. On DigitalOcean, I create a backup of my WordPress, create a new VPS, and rebuild WordPress from the backup. It’s less hassle than dealing with a failed Ubuntu upgrade.

        I find mysqltuner useless. It tells me the problem but doesn’t help me find which configuration parameter will fix it. e.g.

        General recommendations:
        MySQL started within last 24 hours – recommendations may be inaccurate
        When making adjustments, make tmp_table_size/max_heap_table_size equal
        Reduce your SELECT DISTINCT queries which have no LIMIT clause
        Increase table_open_cache gradually to avoid file descriptor limits
        Read this before increasing table_open_cache over 64:
        This is MyISAM only table_cache scalability problem, InnoDB not affected.
        See more details here:
        This bug already fixed in MySQL 5.7.9 and newer MySQL versions.
        Beware that open_files_limit (1024) variable
        should be greater than table_open_cache (431)
        Read this before changing innodb_log_file_size and/or innodb_log_files_in_group:
        Variables to adjust:
        query_cache_size (=0)
        query_cache_type (=0)
        query_cache_limit (> 1M, or use smaller result sets)
        tmp_table_size (> 16M)
        max_heap_table_size (> 16M)
        table_open_cache (> 431)
        innodb_buffer_pool_size (>= 302M) if possible.
        innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

        I do not know into which .cnf file to put query_cache_size or query_cache_type or query_cache_limit.


Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: