If you know that the MyISAM tables are not being actively queried, not only can you ignore recommendations for key_buffer_size, you could actually lower it.
What can you do with the extra RAM you just reclaimed? One or more of the following options:
After restarting mysqld, rerun mysqltuner and evaluate the resulting recommendations. Taking key_buffer_size out of the equation is enough in your instance.
Rather than killing the process, it would be safer if you did it within MySQL:
$ mysqladmin processlist -u root -p
Enter password:
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
| 174 | root | localhost | example | Sleep | 297 | | |
| 407 | root | localhost | | Query | 0 | | show processlist |
+-----+------+-----------+-------------------+---------+------+-------+------------------+
The query with id 174 is the one blocking deletion of the 'example' database, so before you kill any processes first let MySQL try to terminate the query:
$ mysqladmin kill 174
Run the processlist
command above again to confirm that it was killed.
If this doesn't work, then you could perhaps look at killing the errant process, but before that you might try restarting the MySQL server.
You can also run commands like 'SHOW FULL PROCESSLIST' and 'KILL 174' in the MySQL shell, for example if you only have the MySQL client installed. The main point is to avoid killing the process using 'kill' in the shell unless absolutely necessary.
Generally speaking you can use either mysql
or mysqladmin
. You shouldn't need to be running commands like this that often though; once you start killing queries regularly something is definitely wrong and you'd be better off fixing that problem (killing the query process is just treating the symptom).
Best Answer
It funny you asked this. Over 7 years ago (
Jul 11, 2011
), I answered the post What is the point of the TABLE_CATALOG column in INFORMATION_SCHEMA.TABLES?.All I mention there is MySQL trying to be SQL-92 compatible, while PostgreSQL does make actual use of the information_schema (it being localized to whatever database you connected, or as I say in the post "The collapse is automatic").
Due to its open storage engine infrastructure, MySQL's exposure of functions allows for installing your own. For example, in the docs you have this:
I have seen statements like these when installing Percona Server, and Percona supplies three commands to run (like these) to expose parts of Percona Toolkit.
Anyway, going back to your actual question: INFORMATION_SCHEMA gives you nothing than what you already know. Everything else is pluggable.