INNOTOP(1)
💖 INNOTOP 💖
okay bestie, buckle UP, because this is innotop — the manual page for it, anyway. it's a MySQL and InnoDB transaction/status monitor, and it's genuinely iconic. this page is long so we're doing it in parts, but every single fact survives, no cap. 🦋
✨ NAME ✨
innotop — MySQL and InnoDB transaction/status monitor. that's the whole vibe. it watches your database so you don't have to stare at it yourself. 💅
🌸 SYNOPSIS 🌸
to monitor servers the normal way, like a normal person:
innotopto monitor InnoDB status information from a file instead of a live server:
innotop /var/log/mysql/mysqld.errto run innotop non-interactively in a pipe-and-filter configuration (very unix of you):
innotop --count 5 -d 1 -nto monitor a database on another system using a particular username and password:
innotop -u <username> -p <password> -h <hostname>🎀 DESCRIPTION 🎀
so innotop monitors MySQL servers. each of its modes shows you a different aspect of what's happening in the server — like, there's a mode for monitoring replication, one for queries, and one for transactions. and it refreshes its data periodically, so you get a live updating view. it's giving dashboard, it's giving main character energy. 👑
innotop has lots of features for power users, but you can start and run it with virtually no configuration. if you're just getting started, go look at "QUICK-START" below. and press ? at any time while running innotop for context-sensitive help. that key is your bestie fr fr. 🫶
⭐ QUICK-START ⭐
to start innotop, open a terminal or command prompt. if you have installed innotop on your system, you should be able to just type innotop and press Enter; otherwise, you will need to change to innotop's directory and type perl innotop.
with no options specified, innotop will attempt to connect to a MySQL server on localhost using mariadb_read_default_group=client for other connection parameters. if you need to specify a different username and password, use the -u and -p options, respectively. to monitor a MySQL database on another host, use the -h option.
after you've connected, innotop should show you something like the following:
[RO] Query List (? for help) localhost, 01:11:19, 449.44 QPS, 14/7/163 con/run
CXN When Load QPS Slow QCacheHit KCacheHit BpsIn BpsOut
localhost Total 0.00 1.07k 697 0.00% 98.17% 476.83k 242.83k
CXN Cmd ID User Host DB Time Query
localhost Query 766446598 test 10.0.0.1 foo 00:02 INSERT INTO table ((this sample is truncated at the right so it will fit on a terminal when running man innotop — they really said "we're not making the manpage wider than your screen, bestie")
if your server is busy, you'll see more output. notice the first line on the screen, which tells you that readonly is set to true ([RO]), what mode you're in and what server you're connected to. you can change to other modes with keystrokes; press T to switch to a list of InnoDB transactions, for example. so slay.
press the ? key to see what keys are active in the current mode. you can press any of these keys and innotop will either take the requested action or prompt you for more input. if your system has Term::ReadLine support, you can use TAB and other keys to auto-complete and edit input. ✨
to quit innotop, press the q key. bye bestie 👋
💅 OPTIONS 💅
innotop is mostly configured via its configuration file, but some of the configuration options can come from the command line. you can also specify a file to monitor for InnoDB status output; see "MONITORING A FILE" for more details.
you can negate some options by prefixing the option name with --no. for example, --noinc (or --no-inc) negates --inc. little reverse uno card, love that for us. 🙈
--color— Enable or disable terminal coloring. Corresponds to thecolorconfig file setting.--config— Specifies a configuration file to read. This option is non-sticky, that is to say it does not persist to the configuration file itself. it's a one-night-stand option, it does not move in.--count— Refresh only the specified number of times (ticks) before exiting. Each refresh is a pause forintervalseconds, followed by requesting data from MySQL connections and printing it to the terminal.--delay— Specifies the amount of time to pause between ticks (refreshes). Corresponds to the configuration optioninterval.--help— Print a summary of command-line usage and exit. your classic cry for help, but make it useful.--host— Host to connect to.--inc— Specifies whether innotop should display absolute numbers or relative numbers (offsets from their previous values). Corresponds to the configuration optionstatus_inc.--mode— Specifies the mode in which innotop should start. Corresponds to the configuration optionmode.--nonint— Enable non-interactive operation. See "NON-INTERACTIVE OPERATION" for more.--password— Password to use for connection.--port— Port to use for connection.--skipcentral— Don't read the central configuration file.--timestamp— In-nmode, write a timestamp either before every screenful of output, or if the option is given twice, at the start of every line. The format is controlled by thetimeformatconfig variable.--user— User to use for connection.--version— Output version information and exit.--write— Sets the configuration optionreadonlyto0, making innotop write the running configuration to~/.innotop/innotop.confon exit, if no configuration file was loaded at start-up.
🔥 HOTKEYS 🔥
innotop is interactive, and you control it with key-presses. yes, it's a keyboard girlie. 💅
- Uppercase keys switch between modes.
- Lowercase keys initiate some action within the current mode.
- Other keys do something special like change configuration or show the innotop license.
press ? at any time to see the currently active keys and what they do. iykyk. 👑
🌈 MODES 🌈
each of innotop's modes retrieves and displays a particular type of data from the servers you're monitoring. you switch between modes with uppercase keys. the following is a brief description of each mode, in alphabetical order. to switch to the mode, press the key listed in front of its heading in the following list:
- A: Health Dashboard — This mode displays a single table with one row per monitored server. The columns show essential overview information about the server's health, and coloration rules show whether replication is running or if there are any very long-running queries or excessive replication delay. it's the vibe check mode, fr.
- B: InnoDB Buffers — This mode displays information about the InnoDB buffer pool, page statistics, insert buffer, and adaptive hash index. The data comes from
SHOW INNODB STATUS.
This mode contains the buffer_pool, page_statistics, insert_buffers, and adaptive_hash_index tables by default.
- C: Command Summary — This mode is similar to mytop's Command Summary mode. It shows the
cmd_summarytable, which looks something like the following:
Command Summary (? for help) localhost, 25+07:16:43, 2.45 QPS, 3 thd, 5.0.40
_____________________ Command Summary _____________________
Name Value Pct Last Incr Pct
Select_scan 3244858 69.89% 2 100.00%
Select_range 1354177 29.17% 0 0.00%
Select_full_join 39479 0.85% 0 0.00%
Select_full_range_join 4097 0.09% 0 0.00%
Select_range_check 0 0.00% 0 0.00%The command summary table is built by extracting variables from STATUS_VARIABLES. The variables must be numeric and must match the prefix given by the cmd_filter configuration variable. The variables are then sorted by value descending and compared to the last variable, as shown above. The percentage columns are percentage of the total of all variables in the table, so you can see the relative weight of the variables.
The example shows what you see if the prefix is Select_. The default prefix is Com_. You can choose a prefix with the s key.
It's rather like running SHOW VARIABLES LIKE "prefix%" with memory and nice formatting. glow-up edition. ✨
Values are aggregated across all servers. The Pct columns are not correctly aggregated across multiple servers. This is a known limitation of the grouping algorithm that may be fixed in the future. we love an honest queen.
- D: InnoDB Deadlocks — This mode shows the transactions involved in the last InnoDB deadlock. A second table shows the locks each transaction held and waited for. A deadlock is caused by a cycle in the waits-for graph, so there should be two locks held and one waited for unless the deadlock information is truncated.
InnoDB puts deadlock information before some other information in the SHOW INNODB STATUS output. If there are a lot of locks, the deadlock information can grow very large, and there is a limit on the size of the SHOW INNODB STATUS output. A large deadlock can fill the entire output, or even be truncated, and prevent you from seeing other information at all. If you are running innotop in another mode, for example T mode, and suddenly you don't see anything, you might want to check and see if a deadlock has wiped out the data you need. 💀
If it has, you can create a small deadlock to replace the large one. Use the w key to 'wipe' the large deadlock with a small one. This will not work unless you have defined a deadlock table for the connection (see "SERVER CONNECTIONS").
You can also configure innotop to automatically detect when a large deadlock needs to be replaced with a small one (see auto_wipe_dl).
This mode displays the deadlock_transactions and deadlock_locks tables by default.
- F: InnoDB Foreign Key Errors — This mode shows the last InnoDB foreign key error information, such as the table where it happened, when and who and what query caused it, and so on.
InnoDB has a huge variety of foreign key error messages, and many of them are just hard to parse. innotop doesn't always do the best job here, but there's so much code devoted to parsing this messy, unparsable output that innotop is likely never to be perfect in this regard. If innotop doesn't show you what you need to see, just look at the status text directly. sometimes you gotta read the raw tea yourself, ngl.
This mode displays the fk_error table by default.
- I: InnoDB I/O Info — This mode shows InnoDB's I/O statistics, including the I/O threads, pending I/O, file I/O miscellaneous, and log statistics. It displays the
io_threads,pending_io,file_io_misc, andlog_statisticstables by default. - K: InnoDB Lock Waits — This mode shows information from InnoDB plugin's transaction and locking tables. You can use it to find when a transaction is waiting for another, and kill the blocking transaction. It displays the
innodb_blocked_blockertable. goodbye blocker, it's over for you 💅
🔒 L: Locks
okay so this mode 💅 is all about the locks happening right now. as of this exact moment, only InnoDB locks are supported, and by default you're only gonna see the locks that transactions are waiting on. where does this tea come from? the TRANSACTIONS section of the InnoDB status text, bestie. 🔍
if your server is super busy, you'll probably have frequent lock waits — and that's exactly why it's so helpful to see which tables and indexes are the "hot spot" for locks. and if your server is running pretty well? this mode should show nothing. the vibe is immaculate. ✨
you can configure MySQL and innotop to monitor not only the locks a transaction is waiting on, but the ones currently held, too. you do that with the InnoDB Lock Monitor (http://dev.mysql.com/doc/en/innodb-monitor.html). it's not documented in the MySQL manual, but creating the lock monitor with this statement also affects the output of SHOW INNODB STATUS, which innotop uses:
CREATE TABLE innodb_lock_monitor(a int) ENGINE=INNODB;this causes InnoDB to print its output to the MySQL file every 16 seconds or so, as stated in the manual — but it also makes the normal SHOW INNODB STATUS output include lock information, which innotop can parse and display (that's the undocumented feature 🫣).
so this means you can do what may have seemed impossible: to a limited extent (InnoDB truncates some information in the output), you can see which transaction holds the locks that something else is waiting for. you can also enable and disable the InnoDB Lock Monitor with the key mappings in this mode, no cap. 🎀
this mode displays the "innodb_locks" table by default. here's a sample of the screen when one connection is waiting for locks another connection holds:
_________________________________ InnoDB Locks __________________________
CXN ID Type Waiting Wait Active Mode DB Table Index
localhost 12 RECORD 1 00:10 00:10 X test t1 PRIMARY
localhost 12 TABLE 0 00:10 00:10 IX test t1
localhost 12 RECORD 1 00:10 00:10 X test t1 PRIMARY
localhost 11 TABLE 0 00:00 00:25 IX test t1
localhost 11 RECORD 0 00:00 00:25 X test t1 PRIMARYso you can see the first connection, ID 12, is waiting for a lock on the PRIMARY key on test.t1, and has been waiting for 10 seconds. the second connection isn't waiting, because the Waiting column is 0 — but it holds locks on the same index. that tells you connection 11 is blocking connection 12. mystery solved, detective era. 🕵️♀️
🎀 M: Master/Slave Replication Status
this mode shows the output of SHOW SLAVE STATUS and SHOW MASTER STATUS in three tables. the first two divide the slave's status into SQL and I/O thread status, and the last one shows master status. filters get applied to eliminate non-slave servers from the slave tables, and non-master servers from the master table. ✨
this mode displays the "slave_sql_status", "slave_io_status", and "master_status" tables by default.
🌸 O: Open Tables
this section comes from MySQL's SHOW OPEN TABLES command. by default it's filtered to show tables that are in use by one or more queries, so you can get a quick look at which tables are 'hot'. 🔥 you can use this to guess which tables might be locked implicitly. iykyk.
this mode displays the "open_tables" mode by default.
💜 U: User Statistics
this mode displays data that's available in Percona's enhanced version of MySQL (also known as Percona Server with XtraDB). specifically, it makes it easy to enable and disable the so-called "user statistics." this feature gathers stats on clients, threads, users, tables, and indexes and makes them available as INFORMATION_SCHEMA tables. these are invaluable for understanding what your server is doing. they are also available in MariaDB. 👑
the statistics supported so far are only from the TABLE_STATISTICS and INDEX_STATISTICS tables added by Percona. there are three views: one of table stats, one of index stats (which can be aggregated with the = key), and one of both.
the server doesn't gather these stats by default. you have to set the variable userstat_running to turn it on. and bestie, you can do this easily with innotop from U mode, with the s key. so convenient, we love her. 🫶
🦋 Q: Query List
this mode displays the output from SHOW FULL PROCESSLIST, much like mytop's query list mode. it does not show InnoDB-related information. this is probably one of the most useful modes for general usage, fr fr. 💖
there's an informative header that shows general status information about your server. you can toggle it on and off with the h key. by default, innotop hides inactive processes and its own process. you can toggle these on and off with the i and a keys.
you can EXPLAIN a query from this mode with the e key. this displays the query's full text, the results of EXPLAIN, and in newer MySQL versions, even the optimized query resulting from EXPLAIN EXTENDED. innotop also tries to rewrite certain queries to make them EXPLAIN-able. for example, INSERT/SELECT statements are rewritable. the way she just handles that for you 😭💅
this mode displays the "q_header" and "processlist" tables by default.
🌈 R: InnoDB Row Operations and Semaphores
this mode shows InnoDB row operations, row operation miscellaneous, semaphores, and information from the wait array. it displays the "row_operations", "row_operation_misc", "semaphores", and "wait_array" tables by default.
⭐ S: Variables & Status
this mode calculates statistics, such as queries per second, and prints them out in several different styles. you can show absolute values, or incremental values between ticks. 📈
you can switch between the views by pressing a key:
- s prints a single line each time the screen updates, in the style of
vmstat. - g changes the view to a graph of the same numbers, sort of like
tload. - v changes the view to a pivoted table of variable names on the left, with successive updates scrolling across the screen from left to right.
you can choose how many updates to put on the screen with the "num_status_sets" configuration variable.
headers may be abbreviated to fit on the screen in interactive operation. you choose which variables to display with the c key, which selects from predefined sets, or lets you create your own sets. you can edit the current set with the e key. bespoke stats, main character energy. 👑
this mode doesn't really display any tables like other modes do. instead, it uses a table definition to extract and format the data, but then it transforms the result in special ways before outputting it. it uses the "var_status" table definition for this. 🧚
💀 T: InnoDB Transactions
this mode shows transactions from the InnoDB monitor's output, in top-like format. this mode is the reason I wrote innotop. 🥹 (iconic origin story, honestly.)
- you can kill queries or processes with the k and x keys, and
EXPLAINa query with the e or f keys. - InnoDB doesn't print the full query in transactions, so explaining may not work right if the query is truncated. ⚠️
the informational header can be toggled on and off with the h key. by default, innotop hides inactive transactions and its own transaction. you can toggle this on and off with the i and a keys.
this mode displays the "t_header" and "innodb_transactions" tables by default.
✨ INNOTOP STATUS ✨
the first line innotop displays is a "status bar" of sorts. what it contains depends on the mode you're in, and what servers you're monitoring. the first few words are always [RO] (if readonly is set to 1), the innotop mode, such as "InnoDB Txns" for T mode, followed by a reminder to press ? for help at any time. okay helpful queen 💅
ONE SERVER
the simplest case is when you're monitoring a single server. in this case, the name of the connection is next on the status line. this is the name you gave when you created the connection — most likely the MySQL server's hostname. this is followed by the server's uptime. ⏰
if you're in an InnoDB mode, such as T or B, the next word is "InnoDB" followed by some information about the SHOW INNODB STATUS output used to render the screen. the first word is the number of seconds since the last SHOW INNODB STATUS, which InnoDB uses to calculate some per-second statistics. the next is a smiley face indicating whether the InnoDB output is truncated. 🫣
- if the smiley face is
:-), all is well — there is no truncation. 🎀 - a
:^|means the transaction list is so long, InnoDB has only printed out some of the transactions. - finally, a frown
:-(means the output is incomplete, which is probably due to a deadlock printing too much lock information (see "D: InnoDB Deadlocks"). 💀
the next two words indicate the server's queries per second (QPS) and how many threads (connections) exist. finally, the server's version number is the last thing on the line.
MULTIPLE SERVERS
if you are monitoring multiple servers (see "SERVER CONNECTIONS"), the status line does not show any details about individual servers. instead, it shows the names of the connections that are active. again, these are connection names you specified, which are likely to be the server's hostname. a connection that has an error is prefixed with an exclamation point. ❗
if you are monitoring a group of servers (see "SERVER GROUPS"), the status line shows the name of the group. if any connection in the group has an error, the group's name is followed by the fraction of the connections that don't have errors.
see "ERROR HANDLING" for more details about innotop's error handling.
MONITORING A FILE
if you give a filename on the command line, innotop will not connect to ANY servers at all. it will watch the specified file for InnoDB status output and use that as its data source. it will always show a single connection called 'file'. and since it can't connect to a server, it can't determine how long the server it's monitoring has been up — so it calculates the server's uptime as time since innotop started running. vibe-based uptime, we respect it. 🦋
💅 SERVER ADMINISTRATION 💅
okay so yeah, innotop is mostly your lil monitor bestie that lets you watch and analyze your servers 🫶 but plot twist — it can also send commands to servers. the most frequently useful ones are killing queries and stopping or starting slaves. no cap.
you can kill a connection, or — in newer versions of MySQL — kill a query but not the connection, straight from "Q: Query List" and "T: InnoDB Transactions" modes. press k to issue a KILL command, or x to issue a KILL QUERY command. ✨
innotop will prompt you for the server and/or connection ID to kill — tho it does not prompt you if there's only one possible choice for any input, because why bother you, yk? it pre-selects the longest-running query, or the oldest connection. then you confirm the command with y. iconic.
in "Slave Replication Status" in "M: Master" mode, you can start and stop slaves with the a and o keys, respectively 👑. and you can send these commands to many slaves at once. innotop fills in a default command of START SLAVE or STOP SLAVE for you, but lowkey you can actually edit the command and send anything you wish, such as
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1to make the slave skip one binlog event when it starts. cute, right?
you can also ask innotop to calculate the earliest binlog in use by any slave and issue a PURGE MASTER LOGS on the master. use the b key for this 🎀. innotop will prompt you for a master to run the command on, then prompt you for the connection names of that master's slaves (there is no way for innotop to determine this reliably itself, bestie — it's just not gonna guess). innotop will find the minimum binlog in use by these slave connections and suggest it as the argument to PURGE MASTER LOGS.
in "U: User Statistics" mode, you can use the s key to start and stop the collection of the statistics data for TABLE_STATISTICS and similar. 🍓
🌈 SERVER CONNECTIONS 🌈
when you create a server connection using @, innotop asks you for a series of inputs, as follows:
DSN— a DSN is a Data Source Name, which is the initial argument passed to theDBImodule for connecting to a server. it's usually of the form
DBI:MariaDB:;mariadb_read_default_group=mysql;host=HOSTNAMEsince this DSN is passed to the DBD::MariaDB driver, you should read the driver's documentation at <https://metacpan.org/pod/DBD::MariaDB> for the exact details on all the options you can pass the driver in the DSN. you can read more about DBI at <http://dbi.perl.org/docs/>, and especially at <http://search.cpan.org/~timb/DBI/DBI.pm>.
the mariadb_read_default_group=mysql option lets the DBD driver read your MySQL options files, such as ~/.my.cnf on UNIX-ish systems 💜. you can use this to avoid specifying a username or password for the connection. slay.
- InnoDB Deadlock Table — this optional item tells innotop a table name it can use to deliberately create a small deadlock (see "D: InnoDB Deadlocks"). if you specify this option, you just need to be sure the table doesn't exist, and that innotop can create and drop the table with the InnoDB storage engine. you can safely omit or just accept the default if you don't intend to use this. 🧚
- Username — innotop will ask you if you want to specify a username. if you say y, it will then prompt you for a user name. if you have a MySQL option file that specifies your username, you don't have to specify a username.
the username defaults to your login name on the system you're running innotop on.
- Password — innotop will ask you if you want to specify a password. like the username, the password is optional, but there's an additional prompt that asks if you want to save the password in the innotop configuration file. if you don't save it in the configuration file, innotop will prompt you for a password each time it starts. 🫶
⚠️ passwords in the innotop configuration file are saved in plain text, not encrypted in any way. fr fr, no encryption, just vibes and vulnerability. 💀
once you finish answering these questions, you should be connected to a server ✨. but innotop isn't limited to monitoring a single server; you can define many server connections and switch between them by pressing the @ key. see "SWITCHING BETWEEN CONNECTIONS".
🌸 SERVER GROUPS 🌸
if you have multiple MySQL instances, you can put them into named groups, such as 'all', 'masters', and 'slaves', which innotop can monitor all together 🫶. group chat energy, literally.
you can choose which group to monitor with the # key, and you can press the Tab key to switch to the next group. if you're not currently monitoring a group, pressing Tab selects the first group. ✨
to create a group, press the # key and type the name of your new group, then type the names of the connections you want the group to contain. easy.
🦋 SWITCHING BETWEEN CONNECTIONS 🦋
innotop lets you quickly switch which servers you're monitoring. the most basic way is by pressing the @ key and typing the name(s) of the connection(s) you want to use. this setting is per-mode, so you can monitor different connections in each mode, and innotop remembers which connections you choose. memory queen 👑
you can quickly switch to the 'next' connection in alphabetical order with the n key. if you're monitoring a server group (see "SERVER GROUPS") this will switch to the first connection.
you can also type many connection names, and innotop will fetch and display data from them all. just separate the connection names with spaces, for example "server1 server2". again, if you type the name of a connection that doesn't exist, innotop will prompt you for connection information and create the connection. ✨
another way to monitor multiple connections at once is with server groups. you can use the Tab key to switch to the 'next' group in alphabetical order, or if you're not monitoring any groups, Tab will switch to the first group.
🐢 innotop does not fetch data in parallel from connections, so if you are monitoring a large group or many connections, you may notice increased delay between ticks. it's giving "one at a time, bestie."
when you monitor more than one connection, innotop's status bar changes. see "INNOTOP STATUS".
💜 ERROR HANDLING 💜
error handling is not that important when monitoring a single connection, but it's crucial when you have many active connections. a crashed server or lost connection should not crash innotop 🫶. as a result, innotop will continue to run even when there is an error; it just won't display any information from the connection that had an error. because of this, innotop's behavior might confuse you 😭. it's a feature, not a bug! periodt.
innotop does not continue to query connections that have errors, because they may slow innotop and make it hard to use, especially if the error is a problem connecting and causes a long time-out. instead, innotop retries the connection occasionally to see if the error still exists. if so, it will wait until some point in the future. the wait time increases in ticks as the Fibonacci series, so it tries less frequently as time passes. math girlie behavior, honestly iconic ✨
since errors might only happen in certain modes because of the SQL commands issued in those modes, innotop keeps track of which mode caused the error. if you switch to a different mode, innotop will retry the connection instead of waiting. 🔥
by default innotop will display the problem in red text at the bottom of the first table on the screen. you can disable this behavior with the "show_cxn_errors_in_tbl" configuration option, which is enabled by default. if the "debug" option is enabled, innotop will display the error at the bottom of every table, not just the first. and if "show_cxn_errors" is enabled, innotop will print the error text to STDOUT as well. error messages might only display in the mode that caused the error, depending on the mode and whether innotop is avoiding querying that connection. 🎀
🎀 NON-INTERACTIVE OPERATION 🎀
you can run innotop in non-interactive mode, in which case it is entirely controlled from the configuration file and command-line options. to start innotop in non-interactive mode, give the --nonint command-line option. this changes innotop's behavior in the following ways:
- certain Perl modules are not loaded.
Term::Readlineis not loaded, since innotop doesn't prompt interactively.Term::ANSIColorandWin32::Console::ANSImodules are not loaded.Term::ReadKeyis still used, since innotop may have to prompt for connection passwords when starting up. 💅 - innotop does not clear the screen after each tick.
- innotop does not persist any changes to the configuration file.
- if
"--count"is given and innotop is in incremental mode (see "status_inc" and"--inc"), innotop actually refreshes one more time than specified so it can print incremental statistics. this suppresses output during the first tick, so innotop may appear to hang. 😭 don't panic bestie, it's fine. - innotop only displays the first table in each mode. this is so the output can be easily processed with other command-line utilities such as
awkandsed. to change which tables display in each mode, see "TABLES". since "Q: Query List" mode is so important, innotop automatically disables the"q_header"table. this ensures you'll see the"processlist"table, even if you have innotop configured to show theq_headertable during interactive operation. similarly, in "T: InnoDB Transactions" mode, the"t_header"table is suppressed so you see only the"innodb_transactions"table. 🌟 - all output is tab-separated instead of being column-aligned with whitespace, and innotop prints the full contents of each table instead of only printing one screenful at a time. ✨
- innotop only prints column headers once instead of every tick (see "hide_hdr"). innotop does not print table captions (see "display_table_captions"). innotop ensures there are no empty lines in the output. 🧚
- innotop does not honor the
"shorten"transformation, which normally shortens some numbers to human-readable formats. - innotop does not print a status line (see "INNOTOP STATUS"). 💜
✨ CONFIGURING ✨
okay bestie, literally almost EVERYTHING about innotop is configurable 💅. Most stuff you can change right from the built-in commands, but you can also just open up the config file and go feral (carefully).
While you're running innotop, hit the $ key to pop open the configuration editing dialog. Then press another key to pick what kind of data you wanna edit:
S: Statement Sleep Times — edits the SQL statement sleep delays, which make innotop pause for however long you set after executing a statement. See "SQL STATEMENTS" for what each statement is and what it does. By default innotop does not delay after any statements.- This feature is included so you can customize the side-effects caused by monitoring your server. You may not see any effects, but some innotop users have noticed that certain MySQL versions under very high load with InnoDB enabled take longer than usual to execute
SHOW GLOBAL STATUS. If innotop callsSHOW FULL PROCESSLISTimmediately afterward, the processlist contains more queries than the machine actually averages at any given moment. Configuring innotop to pause briefly after callingSHOW GLOBAL STATUSalleviates this effect. - Sleep times are stored in the
stmt_sleep_timessection of the configuration file. Fractional-second sleeps are supported, subject to your hardware's limitations.
- This feature is included so you can customize the side-effects caused by monitoring your server. You may not see any effects, but some innotop users have noticed that certain MySQL versions under very high load with InnoDB enabled take longer than usual to execute
c: Edit Columns — starts the table editor on one of the displayed tables. See "TABLE EDITOR". An alternative way to start the table editor without entering the configuration dialog is with the^key.g: General Configuration — starts the configuration editor to edit global and mode-specific configuration variables (see "MODES"). innotop prompts you to choose a variable from among the global and mode-specific ones depending on the current mode.k: Row-Coloring Rules — starts the row-coloring rules editor on one of the displayed table(s). See "COLORS" for details.p: Manage Plugins — starts the plugin configuration editor. See "PLUGINS" for details.s: Server Groups — lets you create and edit server groups. See "SERVER GROUPS".t: Choose Displayed Tables — lets you choose which tables to display in this mode. See "MODES" and "TABLES".
💖 CONFIGURATION FILE 💖
innotop's default configuration file locations are $HOME/.innotop and /etc/innotop/innotop.conf, and they are looked for in that order. If the first configuration file exists, the second will not be processed 👀. Those can be overridden with the --config command-line option. You can edit it by hand safely, however innotop reads the configuration file when it starts, and, if readonly is set to 0, writes it out again when it exits. Thus, if readonly is set to 0, any changes you make by hand while innotop is running will be lost. rip 💀.
innotop doesn't store its entire configuration in the configuration file. It has a huge set of default configuration values that it holds only in memory, and the configuration file only overrides these defaults. When you customize a default setting, innotop notices, and then stores the customizations into the file. This keeps the file size down, makes it easier to edit, and makes upgrades easier. iconic fr fr.
A configuration file is read-only by default. You can override that with --write. See readonly.
The configuration file is arranged into sections like an INI file. Each section begins with [section-name] and ends with [/section-name]. Each section's entries have a different syntax depending on the data they need to store. You can put comments in the file; any line that begins with a # character is a comment. innotop will not read the comments, so it won't write them back out to the file when it exits. Comments in read-only configuration files are still useful, though.
The first line in the file is innotop's version number. This lets innotop notice when the file format is not backwards-compatible, and upgrade smoothly without destroying your customized configuration. slay.
The following list describes each section of the configuration file and the data it contains:
general
The general section contains global configuration variables and variables that may be mode-specific, but don't belong in any other section. The syntax is a simple key=value list. innotop writes a comment above each value to help you edit the file by hand.
S_func
Controls S mode presentation (see "S: Variables & Status"). If g, values are graphed; if s, values are like vmstat; if p, values are in a pivoted table.
S_set
Specifies which set of variables to display in "S: Variables & Status" mode. See "VARIABLE SETS".
auto_wipe_dl
Instructs innotop to automatically wipe large deadlocks when it notices them. When this happens you may notice a slight delay. At the next tick, you will usually see the information that was being truncated by the large deadlock.
charset
Specifies what kind of characters to allow through the no_ctrl_char transformation. This keeps non-printable characters from confusing a terminal when you monitor queries that contain binary data, such as images.
The default is ascii, which considers anything outside normal ASCII to be a control character. The other allowable values are unicode and none. none considers every character a control character, which can be useful for collapsing ALL text fields in queries.
cmd_filter
This is the prefix that filters variables in "C: Command Summary" mode.
color
Whether terminal coloring is permitted.
cxn_timeout
On MySQL versions 4.0.3 and newer, this variable is used to set the connection's timeout, so MySQL doesn't close the connection if it is not used for a while. This might happen because a connection isn't monitored in a particular mode, for example.
debug
This option enables more verbose errors and makes innotop more strict in some places. It can help in debugging filters and other user-defined code. It also makes innotop write a lot of information to debugfile when there is a crash.
debugfile
A file to which innotop will write information when there is a crash. See "FILES".
display_table_captions
innotop displays a table caption above most tables. This variable suppresses or shows captions on all tables globally. Some tables are configured with the hide_caption property, which overrides this.
global
Whether to show GLOBAL variables and status. innotop only tries to do this on servers which support the GLOBAL option to SHOW VARIABLES and SHOW STATUS. In some MySQL versions, you need certain privileges to do this; if you don't have them, innotop will not be able to fetch any variable and status data. This configuration variable lets you run innotop and fetch what data you can even without the elevated privileges.
I can no longer find or reproduce the situation where GLOBAL wasn't allowed, but I know there was one.
graph_char
Defines the character to use when drawing graphs in "S: Variables & Status" mode.
header_highlight
Defines how to highlight column headers. This only works if Term::ANSIColor is available. Valid values are bold and underline.
hide_hdr
Hides column headers globally.
interval
The interval at which innotop will refresh its data (ticks). The interval is implemented as a sleep time between ticks, so the true interval will vary depending on how long it takes innotop to fetch and render data.
This variable accepts fractions of a second.
mode
The mode in which innotop should start. Allowable arguments are the same as the key presses that select a mode interactively. See "MODES".
num_digits
How many digits to show in fractional numbers and percents. This variable's range is between 0 and 9 and can be set directly from "S: Variables & Status" mode with the + and - keys. It is used in the set_precision, shorten, and percent transformations.
num_status_sets
Controls how many sets of status variables to display in pivoted "S: Variables & Status" mode. It also controls the number of old sets of variables innotop keeps in its memory, so the larger this variable is, the more memory innotop uses.
plugin_dir
Specifies where plugins can be found. By default, innotop stores plugins in the plugins subdirectory of your innotop configuration directory.
readonly
Whether the configuration file is readonly. This cannot be set interactively.
show_cxn_errors
Makes innotop print connection errors to STDOUT. See "ERROR HANDLING".
show_cxn_errors_in_tbl
Makes innotop display connection errors as rows in the first table on screen. See "ERROR HANDLING".
show_percent
Adds a % character after the value returned by the percent transformation.
show_statusbar
Controls whether to show the status bar in the display. See "INNOTOP STATUS".
skip_innodb
Disables fetching SHOW INNODB STATUS, in case your server(s) do not have InnoDB enabled and you don't want innotop to try to fetch it. This can also be useful when you don't have the SUPER privilege, required to run SHOW INNODB STATUS.
spark
Specifies how wide a spark chart is. There are two ASCII spark charts in A mode, showing QPS and User_threads_running.
status_inc
Whether to show absolute or incremental values for status variables. Incremental values are calculated as an offset from the last value innotop saw for that variable. This is a global setting, but will probably become mode-specific at some point. Right now it is honored a bit inconsistently; some modes don't pay attention to it.
timeformat
The C-style strftime()-compatible format for the timestamp line to be printed in -n mode when -t is set.
plugins
This one's just a lil list of package names for your active plugins bestie 💅 — if the plugin's actually there, innotop flips it on. Peep PLUGINS for the deets.
filters
Your homegrown filters live here (go read FILTERS). Every line looks like this:
filter_name=text='filter text' tbls='table list'The filter text is the literal code of the subroutine. The table list is every table that filter's allowed to touch. By default a user-defined filter sticks to the table it was born in, but you can absolutely override that by hand-editing the definition straight in the config file. Iconic behavior honestly.
active_filters
Which filters are currently switched on for each table. Format goes:
table_name=filter_listtbl_meta
This is where user-defined or user-tweaked columns hang out (see COLUMNS). Each line is col_name=properties, and the properties are a name=quoted-value list. Obsessed.
connections
All the server connections you've defined, right here 🫶. Each line is name=properties, properties being a name=value list. They're all pretty self-explanatory — the only one that gets special treatment is pass, and it only shows up if savepass is set. Heads up: this whole section gets skipped if you use any DSN, username, or password command-line options. See SERVER CONNECTIONS.
active_connections
Which connections are live in each mode. Format:
mode_name=connection_listserver_groups
Your server groups, babes. Each line:
name=connection_listSee SERVER GROUPS.
active_server_groups
Which server group is the main character in each mode. Format:
mode_name=server_groupmax_values_seen
The max values ever seen for variables — this is what scales the graphs in S: Variables & Status mode 🌈. Format: name=value.
active_columns
Table column lists. Format: tbl_name=column_list. See COLUMNS.
sort_cols
The sort definition 🎀. Format: tbl_name=column_list. Slap a - in front of a column and it sorts descending. See SORTING.
visible_tables
Which tables you can see in each mode. Format: mode_name=table_list. See TABLES.
varsets
Variable sets for S: Status & Variables mode. Format: name=variable_list. See VARIABLE SETS.
colors
Colorization rules live here, and yes bestie, this is the fun one 💖. Format: tbl_name=property_list. See COLORS.
stmt_sleep_times
Statement sleep times. Format: statement_name=sleep_time. See S: Statement Sleep Times.
group_by
Column lists for table group_by expressions. Format: tbl_name=column_list. See GROUPING.
✨ CUSTOMIZING ✨
Okay so innotop is extremely customizable, like the way that it just lets you do whatever?? For example you can:
- Choose which tables show up, and in what order.
- Choose which columns live in those tables — and make brand new columns.
- Filter which rows display, using built-in filters, user-defined filters, and quick-filters.
- Sort rows so the important data is up top, or so related rows get grouped together.
- Highlight rows with color 🎨.
- Customize the alignment, width, and formatting of columns, and apply transformations to them so you can pull out parts of values or format them however you want (think: shortening huge numbers into familiar units).
- Design your own expressions to extract and combine data exactly how you need. Unlimited flexibility, no cap.
All of this and more is explained in the sections below, so keep reading 👑
TABLES
A table is literally what you'd expect: a lil collection of columns. It's also got other properties, like a caption. Filters, sorting rules, and colorization rules all belong to tables, and we get into those in later sections.
Internally, table meta-data is defined in a data structure called %tbl_meta. This hash holds every built-in table definition, and those definitions carry a lot of default instructions for innotop. The meta-data includes the caption, a list of columns the user has customized, a list of columns, a list of visible columns, a list of filters, color rules, a sort-column list, sort direction, and some info about the table's data sources. Most of that is editable through the table editor — see TABLE EDITOR.
Wanna pick which tables show? Hit the $ key. See MODES and TABLES.
The table life-cycle goes like this:
- Every table starts with a data source, which is an array of hashes. Details on data sources are below.
- Every element of that data source becomes a row in the final table.
- For each element in the data source, innotop extracts values from the source and builds a row. That row is another hash, and later steps call it
$set. Which values innotop extracts is decided by the table's columns — each column has an extraction subroutine, compiled from an expression (see EXPRESSIONS). The resulting row is a hash whose keys are named the same as the column names. - innotop filters the rows, yeeting the ones that don't need to display. See FILTERS.
- innotop sorts the rows. See SORTING.
- innotop groups the rows together, if that's specified. See GROUPING.
- innotop colorizes the rows. See COLORS.
- innotop transforms the column values in each row. See TRANSFORMATIONS.
- innotop optionally pivots the rows (see PIVOTING), then filters and sorts them.
- innotop formats and justifies the rows as a table. During this step innotop applies even more formatting to the column values — alignment, maximum and minimum widths. innotop also does a final error check so nothing crashes on undefined values. Then it adds a caption if one's specified, and the table is ready to print 🎀.
The lifecycle shifts a lil bit if the table is pivoted, like noted above. To be clear: if the table's pivoted, the process is extract, group, transform, pivot, filter, sort, create. If it's not pivoted, the process is extract, filter, sort, group, color, transform, create. Yeah, this slightly convoluted little dance doesn't map all that well to SQL, but pivoting complicates things pretty thoroughly, okay?? Roughly speaking, filtering and sorting happen as late as needed to get the final result you'd expect, but as early as possible for efficiency.
Every built-in table is described below:
adaptive_hash_index— Displays data about InnoDB's adaptive hash index. Data source:STATUS_VARIABLES.buffer_pool— Displays data about InnoDB's buffer pool. Data source:STATUS_VARIABLES.cmd_summary— Displays weighted status variables. Data source:STATUS_VARIABLES.deadlock_locks— Shows which locks were held and waited for by the last detected deadlock. Data source:DEADLOCK_LOCKS.deadlock_transactions— Shows transactions involved in the last detected deadlock. Data source:DEADLOCK_TRANSACTIONS.explain— Shows the output of EXPLAIN. Data source:EXPLAIN.file_io_misc— Displays data about InnoDB's file and I/O operations. Data source:STATUS_VARIABLES.fk_error— Displays various data about InnoDB's last foreign key error. Data source:STATUS_VARIABLES.health_dashboard— Displays an overall summary of servers, one server per line, for monitoring. Data source:STATUS_VARIABLES,MASTER_SLAVE,PROCESSLIST_STATS.index_statistics— Displays data from theINDEX_STATISTICStable in Percona-enhanced servers.index_table_statistics— Displays data from theINDEX_STATISTICSandTABLE_STATISTICStables in Percona-enhanced servers. It joins the two together, grouped by the database and table name. It's the default view in U: User Statistics mode, and it makes it easy to see what tables are hot, how many rows are read from indexes, how many changes are made, and how many changes are made to indexes 🔥.innodb_blocked_blocker— Displays InnoDB locks and lock waits. Data source:INNODB_BLOCKED_BLOCKER.innodb_locks— Displays InnoDB locks. Data source:INNODB_LOCKS.innodb_transactions— Displays data about InnoDB's current transactions. Data source:INNODB_TRANSACTIONS.insert_buffers— Displays data about InnoDB's insert buffer. Data source:STATUS_VARIABLES.io_threads— Displays data about InnoDB's I/O threads. Data source:IO_THREADS.log_statistics— Displays data about InnoDB's logging system. Data source:STATUS_VARIABLES.master_status— Displays replication master status. Data source:STATUS_VARIABLES.open_tables— Displays open tables. Data source:OPEN_TABLES.page_statistics— Displays InnoDB page statistics. Data source:STATUS_VARIABLES.pending_io— Displays InnoDB pending I/O operations. Data source:STATUS_VARIABLES.processlist— Displays current MySQL processes (threads/connections). Data source:PROCESSLIST.q_header— Displays various status values. Data source:STATUS_VARIABLES.row_operation_misc— Displays data about InnoDB's row operations. Data source:STATUS_VARIABLES.row_operations— Displays data about InnoDB's row operations. Data source:STATUS_VARIABLES.semaphores— Displays data about InnoDB's semaphores and mutexes. Data source:STATUS_VARIABLES.slave_io_status— Displays data about the slave I/O thread. Data source:STATUS_VARIABLES.slave_sql_status— Displays data about the slave SQL thread. Data source:STATUS_VARIABLES.table_statistics— Displays data from theTABLE_STATISTICStable in Percona-enhanced servers.t_header— Displays various InnoDB status values. Data source:STATUS_VARIABLES.var_status— Displays user-configurable data. Data source:STATUS_VARIABLES.wait_array— Displays data about InnoDB's OS wait array. Data source:OS_WAIT_ARRAY.
✨ COLUMNS ✨
Okay so, columns live inside tables, right? Like, a table is the whole vibe and columns are the individual flexes inside it. To pick which ones you wanna see, hit the ^ key — that opens the "TABLE EDITOR" and lets you choose and edit columns to your heart's content. And once you're inside the table editor, pressing e lets you actually edit a column's properties, which are:
hdr— the column header, aka the lil label that shows up in the very first row of the table. 💖just— justification, bestie.'-'means left-justified, and''means right-justified, exactly likeprintfformatting codes (and no, that is not a coincidence, they literally stole it).dec— whether to align the column even further on the decimal point. Yes really.num— is this column numeric or not? This decides how values get sorted — lexically or numerically. Whole different energy tbh.label— a small note about the column that shows up in dialogs that help you pick columns. Helpful lil guy.src— an expression innotop uses to pull the column's data out of its source (go peek at "DATA SOURCES"). And for more on expressions, "EXPRESSIONS" has you covered.minw— sets a minimum display width. This keeps the display stable so it's actually readable when the data is changing every five seconds, which, mood.maxw— basically the same thing asminw, but the other direction.trans— a list of column transformations. See "TRANSFORMATIONS".agg— an aggregate function. See "GROUPING". The default here is"first".aggonly— controls whether the column only shows when grouping is turned on for the table (again, see "GROUPING"). By default this is disabled, which means columns always show by default whether grouping is on or off. But if a column'saggonlyis set to true, it only appears once you toggle grouping on. Several columns are set this way — like the count column on"processlist"and"innodb_transactions"— so you don't get a count when grouping is off, but you do when it's on. Iconic behavior honestly.agghide— the reverse ofaggonly. This column gets hidden whenever grouping is enabled.
🌸 FILTERS 🌸
Filters? They remove rows from your display. And they act a LOT like a WHERE clause in SQL. innotop ships with several built-in filters that strip out irrelevant noise like inactive queries, but bestie you can absolutely define your own. innotop also lets you make quick-filters, which do NOT get saved to the configuration file — they're just a fast lil way to peek at only some rows.
You can enable or disable a filter on any table. Press % — mnemonic: % kinda looks like a line being filtered between two circles, which is honestly adorable — and then pick which table you wanna filter, if it asks. You'll see a list of possible filters plus a list of filters that are currently enabled for that table. Just type the names of the filters you want and hit Enter. Slay.
💖 USER-DEFINED FILTERS 💖
If you type a name that doesn't exist, innotop will prompt you to create that filter. Creating filters is easy-peasy if you know Perl, and honestly not hard even if you don't. What you're doing is writing a subroutine that returns true if the row should be shown. The row itself is a hash reference that gets passed into your subroutine as $set.
So like, imagine you want to filter the processlist table so you only see queries that have been running more than five minutes. Type a fresh name for your filter, and when it asks you for the subroutine body, press TAB to kick off your terminal's auto-completion. You'll see the names of the columns in the "processlist" table (innotop generally tries to help you out with auto-completion lists, sweetie). You want to filter on the 'time' column. So type the text "$set->{time} > 300" to return true when the query is more than five minutes old. That's it. That's the whole thing.
In other words, the code you're typing lives inside an implicit context that looks like this:
sub filter {
my ( $set ) = @_;
# YOUR CODE HERE
}If your filter doesn't work, or if something else suddenly starts acting weird, you might have made an error in your filter and innotop is just silently catching it. Try enabling "debug" so innotop throws an error instead of quietly letting you suffer. 😭
🦋 QUICK-FILTERS 🦋
innotop's quick-filters are a shortcut for making a temporary filter that does NOT stick around when you restart innotop. To make one, press /. innotop prompts you for the column name and the filter text. And again, auto-completion works on column names, love that for you. The filter text can just be the text you want to "search for." So for example, to filter the "processlist" table down to queries that mention the products table, type / and then 'info product'. Internally the filter gets compiled into a subroutine like this:
sub filter {
my ( $set ) = @_;
$set->{info} =~ m/product/;
}The filter text can actually be any Perl regular expression, but of course a literal string like 'product' works perfectly fine as a regex too.
Now — what if you want the filter to discard matching rows instead of showing them? 👀 If you're familiar with Perl regexes you might already guess how this goes. You have to use a zero-width negative lookahead assertion. And if you have no idea what that means, don't even worry about it. Let's filter out all rows where the command is Gandalf. Type the following:
1. /
2. cmd ^(?!Gandalf)Behind the scenes, innotop compiles the quick-filter into a specially tagged filter that's otherwise exactly like any other filter. It just doesn't get saved to the configuration file. Periodt.
And to clear quick-filters? Press \ and innotop clears them all at once. Boom, clean slate. ✨
🔥 SORTING 🔥
innotop has sensible built-in defaults that sort the most important rows to the top of the table, because it loves you. And like everything else in innotop, you can customize how any table is sorted.
To start the sort dialog: open the "TABLE EDITOR" with the ^ key, choose a table if you need to, then press s. You'll see a list of columns you can use in the sort expression and the current sort expression, if there even is one. Type in the list of columns you wanna sort by and hit Enter. Wanna reverse sort? Prefix the column name with a minus sign. So for example, if you want to sort by column a ascending and then column b descending, type 'a -b'. You can also explicitly slap a + in front of columns you want ascending, but it's not required, so don't stress it.
Some modes have keys mapped to open this dialog directly and to quickly flip the sort direction. Press ? like usual to see which keys are mapped in any mode. iykyk. 💅
👑 GROUPING 👑
innotop can group, or aggregate, rows together — and yes, the terms get used interchangeably, keep up bestie. This is pretty similar to an SQL GROUP BY clause. You can group on certain columns, or if you don't specify any, the entire set of rows is treated as one single group. So far so SQL, right? But here's the twist: unlike SQL, you can also select un-grouped columns. innotop actually aggregates every column. And if you don't explicitly give it a grouping function, the default is 'first' — which is basically a convenience so you don't have to name an aggregate function for every single column in the result.
You can quickly toggle grouping on a table with the = key, which toggles its aggregate property. Quick heads up though: this property does NOT persist to the config file.
The columns a table gets grouped by are specified in its group_by property. When you turn grouping on, innotop moves the group_by columns to the far left of the table — even if they're not supposed to be visible. Then the rest of the visible columns show up in order after them.
Two tables come with default group_by lists and a built-in count column: "processlist" and "innodb_transactions". The grouping is by connection and status, so you can instantly see how many queries or transactions are in a given status on each server you're monitoring. The time columns get aggregated as a sum; other columns just hang out at the default 'first' aggregation.
By default, the table shown in "S: Variables & Status" mode also uses grouping, so you can monitor variables and status across tons of servers at once. And the default aggregation function in that mode is 'avg'. 😌
The valid grouping functions are defined in the %agg_funcs hash, and they are:
first— Returns the first element in the group.count— Returns the number of elements in the group, including undefined elements, a lot like SQL'sCOUNT(*).avg— Returns the average of the defined elements in the group.sum— Returns the sum of the elements in the group.
Here's grouping in action, so you can see the vision. Say you've got a very busy server with hundreds of open connections and you wanna know how many connections are in what status. Using the built-in grouping rules, press Q to enter "Q: Query List" mode. Then press = to toggle grouping (and if it asks, pick the "processlist" table when prompted, obvs).
Your display might now look like the following:
Query List (? for help) localhost, 32:33, 0.11 QPS, 1 thd, 5.0.38-log
CXN Cmd Cnt ID User Host Time Query
localhost Query 49 12933 webusr localhost 19:38 SELECT * FROM
localhost Sending Da 23 2383 webusr localhost 12:43 SELECT col1,
localhost Sleep 120 140 webusr localhost 5:18:12
localhost Statistics 12 19213 webusr localhost 01:19 SELECT * FROMOkay so… that's actually kind of an alarming picture, ngl. 😭 You've got a TON of idle connections (Sleep), plus some connections actually executing queries (Query and Sending Data). That part's fine, whatever. But you've also got a whole bunch sitting in Statistics status, collectively spending over a minute. That means the query optimizer is having an absolutely terrible time generating execution plans for your statements. Something is wrong — it should normally take milliseconds to plan queries. And you might never have noticed this pattern if you hadn't looked at your connections in aggregate. (Yes, this is a made-up example, but it 100% happens in real life.)
💅 PIVOTING 💅
innotop can pivot a table for a more compact display — similar to a Pivot Table in a spreadsheet, a.k.a. a crosstab. Pivoting a table turns columns into rows. Say you start with this table:
foo bar
=== ===
1 3
2 4After pivoting, the table looks like this:
name set0 set1
==== ==== ====
foo 1 2
bar 3 4And to get reasonable results you might need to group as well as pivot. innotop currently does exactly that for "S: Variables & Status" mode. 🫶
🌈 COLORS 🌈
By default, innotop highlights rows with color so you can tell at a glance which rows are more important — main character rows get main character treatment. 👑 And you can customize the colorization rules and add your own to any table. Just open the table editor with the ^ key, choose a table if needed, and press o to open the color editor dialog. Go make it pretty. 💖
The color editor dialog shows you every rule that's getting applied to your table, in the exact order they get checked. 💅 Each row gets tested against each rule to see if it matches — and if it does? That row gets the color, and nothing else gets evaluated. One and done. The rules look like this:
state eq Locked black on_red
cmd eq Sleep white
user eq system user white
cmd eq Connect white
cmd eq Binlog Dump white
time > 600 red
time > 120 yellow
time > 60 green
time > 30 cyanThis is the default rule set for the "processlist" table, bestie. In order of priority, these rules make locked queries black on a red background, "gray out" connections from replication and sleeping queries, and make queries turn from cyan to red as they run longer. It's giving traffic light but make it SQL. 🚦
(For some reason, the ANSI color code "white" is actually a light gray. Your terminal's display may vary; experiment to find colors you like). 🙈
You can use keystrokes to move the rules up and down, which re-orders their priority. You can also delete rules and add new ones. If you add a new rule, innotop prompts you for the column, an operator for the comparison, a value against which to compare the column, and a color to assign if the rule matches. There is auto-completion and prompting at each step. It's honestly so hand-holdy and I love that for us. 🫶
The value in the third step needs to be correctly quoted. innotop does not try to quote the value because it doesn't know whether it should treat the value as a string or a number. If you want to compare the column against a string, as for example in the first rule above, you should enter 'Locked' surrounded by quotes. If you get an error message about a bareword, you probably should have quoted something. 😭
EXPRESSIONS ✨
Expressions are literally the core of how innotop works, and they're what enables you to extend innotop as you wish. Recall the table lifecycle explained in "TABLES". Expressions are used in the earliest step, where it extracts values from a data source to form rows.
It does this by calling a subroutine for each column, passing it the source data set, a set of current values, and a set of previous values. These are all needed so the subroutine can calculate things like the difference between this tick and the previous tick. ⏱️
The subroutines that extract the data from the set are compiled from expressions. This gives significantly more power than just naming the values to fill the columns, because it allows the column's value to be calculated from whatever data is necessary, but avoids the need to write complicated and lengthy Perl code.
innotop begins with a string of text that can look as simple as a value's name or as complicated as a full-fledged Perl expression. It looks at each 'bareword' token in the string and decides whether it's supposed to be a key into the $set hash. A bareword is an unquoted value that isn't already surrounded by code-ish things like dollar signs or curly brackets. If innotop decides that the bareword isn't a function or other valid Perl code, it converts it into a hash access. After the whole string is processed, innotop compiles a subroutine, like this:
sub compute_column_value {
my ( $set, $cur, $pre ) = @_;
my $val = # EXPANDED STRING GOES HERE
return $val;
}Here's a concrete example, taken from the header table "q_header" in "Q: Query List" mode. This expression calculates the qps, or Queries Per Second, column's values, from the values returned by SHOW STATUS:
Questions/Uptime_hiresinnotop decides both words are barewords, and transforms this expression into the following Perl code:
$set->{Questions}/$set->{Uptime_hires}When surrounded by the rest of the subroutine's code, this is executable Perl that calculates a high-resolution queries-per-second value. Iconic. 👑
The arguments to the subroutine are named $set, $cur, and $pre. In most cases, $set and $cur will be the same values. However, if "status_inc" is set, $cur will not be the same as $set, because $set will already contain values that are the incremental difference between $cur and $pre. 🌀
Every column in innotop is computed by subroutines compiled in the same fashion. There is no difference between innotop's built-in columns and user-defined columns. This keeps things consistent and predictable. Periodt. 💯
TRANSFORMATIONS 🦋
Transformations change how a value is rendered. For example, they can take a number of seconds and display it in H:M:S format. The following transformations are defined:
commify— Adds commas to large numbers every three decimal places.distill— Distills SQL into verb-noun-noun format for quick comprehension.dulint_to_int— Accepts two unsigned integers and converts them into a single longlong. This is useful for certain operations with InnoDB, which uses two integers as transaction identifiers, for example.fuzzy_time— Converts a number of seconds into a friendly, readable value like"1h35m".no_ctrl_char— Removes quoted control characters from the value. This is affected by the"charset"configuration variable.
This transformation only operates within quoted strings, for example, values to a SET clause in an UPDATE statement. It will not alter the UPDATE statement, but will collapse the quoted string to [BINARY] or [TEXT], depending on the charset.
percent— Converts a number to a percentage by multiplying it by two, formatting it with"num_digits"digits after the decimal point, and optionally adding a percent sign (see"show_percent").secs_to_time— Formats a number of seconds as time indays+hours:minutes:secondsformat.set_precision— Formats numbers with"num_digits"number of digits after the decimal point.shorten— Formats a number as a unit of 1024 (k/M/G/T) and with"num_digits"number of digits after the decimal point.
TABLE EDITOR 🎀
The innotop table editor lets you customize tables with keystrokes. You start the table editor with the ^ key. If there's more than one table on the screen, it will prompt you to choose one of them. Once you do, innotop will show you something like this:
Editing table definition for Buffer Pool. Press ? for help, q to quit.
name hdr label src
cxn CXN Connection from which cxn
buf_pool_size Size Buffer pool size IB_bp_buf_poo
buf_free Free Bufs Buffers free in the b IB_bp_buf_fre
pages_total Pages Pages total IB_bp_pages_t
pages_modified Dirty Pages Pages modified (dirty IB_bp_pages_m
buf_pool_hit_rate Hit Rate Buffer pool hit rate IB_bp_buf_poo
total_mem_alloc Memory Total memory allocate IB_bp_total_m
add_pool_alloc Add'l Pool Additional pool alloca IB_bp_add_pooThe first line shows which table you're editing, and reminds you again to press ? for a list of key mappings. The rest is a tabular representation of the table's columns, because that's likely what you're trying to edit. However, you can edit more than just the table's columns — this screen can start the filter editor, color rule editor, and more. 🙈
Each row in the display shows a single column in the table you're editing, along with a couple of its properties such as its header and source expression (see "EXPRESSIONS").
The key mappings are Vim-style, as in many other places. Pressing j and k moves the highlight up or down. You can then delete or edit the highlighted column. You can also add a column to the table. This actually just activates one of the columns already defined for the table; it prompts you to choose from among the columns available but not currently displayed. Finally, you can re-order the columns with the + and - keys. 💅
You can do more than just edit the columns with the table editor, you can also edit other properties, such as the table's sort expression and group-by expression. Press ? to see the full list, of course.
If you want to really customize and create your own column, as opposed to just activating a built-in one that's not currently displayed, press the new key, and innotop will prompt you for the information it needs:
- The column name: this needs to be a word without any funny characters, e.g. just letters, numbers and underscores.
- The column header: this is the label that appears at the top of the column, in the table header. This can have spaces and funny characters, but be careful not to make it too wide and waste space on-screen.
- The column's data source: this is an expression that determines what data from the source (see
"TABLES") innotop will put into the column. This can just be the name of an item in the source, or it can be a more complex expression, as described in"EXPRESSIONS".
Once you've entered the required data, your table has a new column. There is no difference between this column and the built-in ones; it can have all the same properties and behaviors. innotop will write the column's definition to the configuration file, so it will persist across sessions. 🌟
Here's an example: suppose you want to track how many times your slaves have retried transactions. According to the MySQL manual, the Slave_retried_transactions status variable gives you that data: "The total number of times since startup that the replication slave SQL thread has retried transactions. This variable was added in version 5.0.4." This is appropriate to add to the "slave_sql_status" table.
To add the column, switch to the replication-monitoring mode with the M key, and press the ^ key to start the table editor. When prompted, choose slave_sql_status as the table, then press n to create the column. Type 'retries' as the column name, 'Retries' as the column header, and 'Slave_retried_transactions' as the source. Now the column is created, and you see the table editor screen again. Press q to exit the table editor, and you'll see your column at the end of the table. Ate and left no crumbs. 🍓
🧚 VARIABLE SETS 🧚
Okay bestie, so variable sets are what you use inside "S: Variables & Status" mode to tell innotop exactly which variables you wanna keep an eye on. Under the hood? They get compiled into a list of expressions, and then into a column list, so innotop can treat them exactly like columns in any other table — same data extraction, same transformations, the whole slay. But you, gorgeous, are fully protected from all those tedious little details, because the syntax they hand you is one you already know and love: a SQL SELECT list. 💅
The data source for variable sets (and honestly for the entire S mode) is the combo of SHOW STATUS, SHOW VARIABLES, and SHOW INNODB STATUS. Picture a giant table with one column per variable returned from those statements — that's the data source. And now you just query it like you'd expect. For example:
Questions, Uptime, Questions/Uptime as QPSBehind the scenes innotop splits that variable set into three expressions, compiles them, turns them into a table definition, then extracts as usual. And boom — that's a "variable set," aka a "list of variables you want to monitor." Obsessed, honestly.
innotop lets you name and save your variable sets, and it writes them to the configuration file. Pick which one you wanna see with the c key, or flip to the next and previous sets with the > and < keys. There are lots of built-in variable sets too, which should give you a genuinely good starting point for making your own. Hit e to edit the current variable set, or just to peek at how it's defined. Wanna make a brand-new one? Just press c and type its name. ✨
You might wanna use some of the functions listed in "TRANSFORMATIONS" to help format your results. In particular, "set_precision" is often useful to limit the number of digits you see. Extending the example above, here's how:
Questions, Uptime, set_precision(Questions/Uptime) as QPSNgl though, this still needs a little more work. If your "interval" is less than one second, you might be dividing by zero, because Uptime is incremental in this mode by default. So instead, use Uptime_hires:
Questions, Uptime, set_precision(Questions/Uptime_hires) as QPSThis example is simple, but it shows how easy it is to pick which variables you wanna monitor. 🫶
🔥 PLUGINS 🔥
innotop has a simple but powerful plugin mechanism, so you can extend or modify its existing functionality, and add brand-new functionality too. The plugin functionality is event-based: plugins register themselves to be called when events happen, and then they get a chance to influence the event. Main character energy, honestly.
An innotop plugin is a Perl module (.pm) file placed in innotop's "plugin_dir" directory. On UNIX systems, you can place a symbolic link to the module instead of putting the actual file there — cute. innotop automatically discovers files named *.pm. If there's a corresponding entry in the "plugins" configuration file section, innotop loads and activates the plugin.
The module must conform to innotop's plugin interface. Also — plot twist — the source code of the module must be written so innotop can inspect the file and determine the package name and description.
🌸 Package Source Convention 🌸
innotop inspects the plugin module's source to figure out the Perl package name. It looks for a line of the form package Foo; and if it finds it, considers the plugin's package name to be Foo. And of course the package name can be a valid Perl package name such as Foo::Bar, with double colons (::) and so on and so forth.
It also looks for a description in the source code, to make the plugin editor more human-friendly. The description is a comment line of the form # description: Foo, where "Foo" is the text innotop will treat as the plugin's description. 🎀
🦋 Plugin Interface 🦋
The innotop plugin interface is quite simple: innotop expects the plugin to be an object-oriented module it can call certain methods on. The methods are:
new(%variables)— This is the plugin's constructor. It gets passed a hash of innotop's variables, which it can manipulate (see"Plugin Variables"). It must return a reference to the newly created plugin object.
At construction time, innotop has only loaded the general configuration and created the default built-in variables with their default contents (which is quite a lot, fr). So the state of the program is exactly as in the innotop source code, plus the configuration variables from the "general" section in the config file.
If your plugin manipulates the variables, it's changing global data, which is shared by innotop and all plugins. Plugins are loaded in the order they're listed in the config file. Your plugin may load before or after another plugin, so there's a potential for conflict or interaction between plugins if they modify data other plugins use or modify. ⚠️
register_for_events()— This method must return a list of events in which the plugin is interested, if any. See"Plugin Events"for the defined events. If the plugin returns an event that's not defined, the event is simply ignored. Bye. 👋- event handlers — The plugin must implement a method named the same as each event for which it has registered. In other words, if the plugin returns
qw(foo bar)fromregister_for_events(), it must havefoo()andbar()methods. These methods are callbacks for the events. See"Plugin Events"for more details about each event.
💜 Plugin Variables 💜
The plugin's constructor is passed a hash of innotop's variables, which it can manipulate. It's probably a good idea for the plugin object to save a copy of it for later use. The variables are defined in the innotop variable %pluggable_vars, and they go a little something like this:
action_for— A hashref of key mappings. These are innotop's global hot-keys.agg_funcs— A hashref of functions that can be used for grouping. See"GROUPING".config— The global configuration hash.connections— A hashref of connection specifications. These are just specifications of how to connect to a server.dbhs— A hashref of innotop's database connections. These are actual DBI connection objects.filters— A hashref of filters applied to table rows. See"FILTERS"for more.modes— A hashref of modes. See"MODES"for more.server_groups— A hashref of server groups. See"SERVER GROUPS".tbl_meta— A hashref of innotop's table meta-data, with one entry per table (see"TABLES"for more information).trans_funcs— A hashref of transformation functions. See"TRANSFORMATIONS".var_sets— A hashref of variable sets. See"VARIABLE SETS".
⭐ Plugin Events ⭐
Each event is defined somewhere in the innotop source code. When innotop runs that code, it executes the callback function for each plugin that expressed its interest in the event. innotop passes some data for each event. The events are defined in the %event_listener_for variable, and they are as follows:
extract_values($set, $cur, $pre, $tbl)— This event occurs inside the function that extracts values from a data source. The arguments are the set of values, the current values, the previous values, and the table name.set_to_tbl— Events are defined at many places in this subroutine, which is responsible for turning an arrayref of hashrefs into an arrayref of lines that can be printed to the screen. The events all pass the same data: an arrayref of rows and the name of the table being created. The events areset_to_tbl_pre_filter,set_to_tbl_pre_sort,set_to_tbl_pre_group,set_to_tbl_pre_colorize,set_to_tbl_pre_transform,set_to_tbl_pre_pivot,set_to_tbl_pre_create,set_to_tbl_post_create.draw_screen($lines)— This event occurs inside the subroutine that prints the lines to the screen.$linesis an arrayref of strings.
🌈 Simple Plugin Example 🌈
The easiest way to explain the plugin functionality is probably with a simple example. The following module adds a column to the beginning of every table and sets its value to 1. (If you copy and paste this example code, be sure to remove the first space from each line; lines such as '# description' must not start with whitespace.)
use strict;
use warnings FATAL => 'all';
package Innotop::Plugin::Example;
# description: Adds an 'example' column to every table
sub new {
my ( $class, %vars ) = @_;
# Store reference to innotop's variables in $self
my $self = bless { %vars }, $class;
# Design the example column
my $col = {
hdr => 'Example',
just => '',
dec => 0,
num => 1,
label => 'Example',
src => 'example', # Get data from this column in the data source
tbl => '',
trans => [],
};
# Add the column to every table.
my $tbl_meta = $vars{tbl_meta};
foreach my $tbl ( values %$tbl_meta ) {
# Add the column to the list of defined columns
$tbl->{cols}->{example} = $col;
# Add the column to the list of visible columns
unshift @{$tbl->{visible}}, 'example';
}
# Be sure to return a reference to the object.
return $self;
}
# I'd like to be called when a data set is being rendered into a table, please.
sub register_for_events {
my ( $self ) = @_;
return qw(set_to_tbl_pre_filter);
}
# This method will be called when the event fires.
sub set_to_tbl_pre_filter {
my ( $self, $rows, $tbl ) = @_;
# Set the example column's data source to the value 1.
foreach my $row ( @$rows ) {
$row->{example} = 1;
}
}
1;🎀 Plugin Editor 🎀
The plugin editor lets you view the plugins innotop discovered and activate or deactivate them. Start the editor by pressing $ to start the configuration editor from any mode. Press the p key to start the plugin editor. You'll see a list of the plugins innotop discovered. Use the j and k keys to move the highlight to the one you want, then press the * key to toggle it active or inactive. Exit the editor and restart innotop for the changes to take effect. ✨
💾 SQL STATEMENTS 💾
okay so bestie, here's the tea: innotop keeps its SQL super limited. it only uses a small set of statements to pull data out of MySQL for display. and it's smart about it — the statements get customized depending on the server version they're being run against. for example, on MySQL 5 and newer, INNODB_STATUS executes SHOW ENGINE INNODB STATUS, while on earlier versions it executes SHOW INNODB STATUS. periodt. the statements are as follows:
INDEX_STATISTICS—SELECT * FROM INFORMATION_SCHEMA.INDEX_STATISTICSINNODB_STATUS—SHOW [ENGINE] INNODB STATUSKILL_CONNECTION—KILLKILL_QUERY—KILL QUERYOPEN_TABLES—SHOW OPEN TABLESPROCESSLIST—SHOW FULL PROCESSLISTSHOW_MASTER_LOGS—SHOW MASTER LOGSSHOW_MASTER_STATUS—SHOW MASTER STATUSSHOW_SLAVE_STATUS—SHOW SLAVE STATUSSHOW_STATUS—SHOW [GLOBAL] STATUSSHOW_VARIABLES—SHOW [GLOBAL] VARIABLESTABLE_STATISTICS—SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS
🌈 DATA SOURCES 🌈
every single time innotop pulls values together to build a table (peep "EXPRESSIONS" and "TABLES" for that whole situation), it's doing it from one specific data source. and ngl, largely because of all the ridiculously complex data it digs out of SHOW INNODB STATUS, this is a little bit messy. SHOW INNODB STATUS is giving mixed bag — it's got single values AND repeated values that form nested data sets. iconic but chaotic.
also, whenever innotop fetches data from MySQL, it adds two extra bits to every set: cxn and Uptime_hires. cxn is the name of the connection the data came from. Uptime_hires is a high-resolution version of the server's Uptime status variable — and lowkey this one matters a LOT if your "interval" setting is sub-second. 👑
here are the kinds of data sources data gets extracted from:
STATUS_VARIABLES
the broadest category, and the one the most kinds of data fall into. it kicks off with the combo of SHOW STATUS and SHOW VARIABLES, but other sources can get pulled in as needed — for example, SHOW MASTER STATUS and SHOW SLAVE STATUS, plus a bunch of the non-repeated values from SHOW INNODB STATUS. she contains multitudes. 💅
DEADLOCK_LOCKS
pulled from the transaction list in the LATEST DETECTED DEADLOCK section of SHOW INNODB STATUS. it's nested two levels deep: transactions, then locks. very layers-on-layers of her.
DEADLOCK_TRANSACTIONS
from the transaction list in the LATEST DETECTED DEADLOCK section of SHOW INNODB STATUS. only nested one level deep this time. we love a lower-maintenance data source.
EXPLAIN
from the result set returned by EXPLAIN. simple. clean. no notes.
INNODB_BLOCKED_BLOCKER
from the INFORMATION_SCHEMA tables related to InnoDB locks and the processlist. the name really said it all ngl.
INNODB_TRANSACTIONS
from the TRANSACTIONS section of SHOW INNODB STATUS.
IO_THREADS
from the list of threads in the FILE I/O section of SHOW INNODB STATUS.
INNODB_LOCKS
from the TRANSACTIONS section of SHOW INNODB STATUS, and yes bestie it is nested two levels deep. she's complex, she's layered, we respect her. 🧚
MASTER_SLAVE
from the combination of SHOW MASTER STATUS and SHOW SLAVE STATUS.
OPEN_TABLES
from SHOW OPEN TABLES.
PROCESSLIST
from SHOW FULL PROCESSLIST.
PROCESSLIST_STATS
from SHOW FULL PROCESSLIST, and it computes stats like the maximum time a user query has been running, plus how many user queries are running. quick definition drop: a "user query" excludes replication threads. don't come for me, that's just the rules. ✨
OS_WAIT_ARRAY
from the SEMAPHORES section of SHOW INNODB STATUS, nested one level deep. it comes from the lines that look like this:
--Thread 1568861104 has waited at btr0cur.c line 424 ....🔐 MYSQL PRIVILEGES 🔐
bestie, permissions are the whole vibe check here. listen up:
- You must connect to MySQL as a user who has the
SUPERprivilege for many of the functions. - If you don't have the
SUPERprivilege, you can still run some functions, but you won't necessarily see all the same data. 😭 it's giving partial view. - You need the
PROCESSprivilege to see the list of currently running queries in Q mode. - You need special privileges to start and stop slave servers.
- You need appropriate privileges to create and drop the deadlock tables if needed (see "SERVER CONNECTIONS").
🛠️ SYSTEM REQUIREMENTS 🛠️
so, to run innotop you need Perl, obviously. 💖 you also need a few Perl modules: DBI, DBD::MariaDB, Term::ReadKey, and Time::HiRes. these should already be included with most Perl distributions, but just in case they're not — the recommendation is to use versions distributed with your operating system or Perl distribution, not from CPAN. and specifically, Term::ReadKey has been known to cause problems if installed from CPAN. so like. be careful. 🙈
if you have Term::ANSIColor, innotop will use it to format headers more readably and compactly. (heads up: under Microsoft Windows, you also need Win32::Console::ANSI for terminal formatting codes to be honored). and if you install Term::ReadLine, preferably Term::ReadLine::Gnu, you'll get nice auto-completion support. slay. ⭐
innotop has been run on Gentoo GNU/Linux, Debian and Ubuntu, and there's feedback from people successfully running it on Red Hat, CentOS, Solaris, and Mac OSX. there's no reason to think it won't work on other UNIX-ish operating systems, but that's not confirmed for sure. it also runs on Windows under ActivePerl without problem. 🌈
innotop has been used on MySQL versions 3.23.58, 4.0.27, 4.1.0, 4.1.22, 5.0.26, 5.1.15, and 5.2.3. and if it doesn't run correctly for you? that's a bug, and it should be reported. no cap. 🐛
📁 FILES 📁
$HOMEDIR/.innotop and/or /etc/innotop are used to store configuration information. the files include the configuration file innotop.conf, the core_dump file (which contains verbose error messages if "debug" is enabled), and the plugins/ subdirectory. cute little home base for everything. 🎀
📖 GLOSSARY OF TERMS 📖
tick
A tick is a refresh event, when innotop re-fetches data from connections and displays it. that's it, that's the term. she's simple like that. 💜
🫶 ACKNOWLEDGEMENTS 🫶
the following people and organizations are acknowledged for various reasons. hopefully no one has been forgotten. (if you were, i am SO sorry, it was not personal 🥺)
Aaron Racine, Allen K. Smith, Aurimas Mikalauskas, Bartosz Fenski, Brian Miezejewski, Christian Hammers, Cyril Scetbon, Dane Miller, David Multer, Dr. Frank Ullrich, Giuseppe Maxia, Google.com Site Reliability Engineers, Google Code, Jan Pieter Kunst, Jari Aalto, Jay Pipes, Jeremy Zawodny, Johan Idren, Kristian Kohntopp, Lenz Grimmer, Maciej Dobrzanski, Michiel Betel, MySQL AB, Paul McCullagh, Sebastien Estienne, Sourceforge.net, Steven Kreuzer, The Gentoo MySQL Team, Trevor Price, Yaar Schnitman, and probably more people that have not been included.
(also, if your name has been misspelled, it's probably out of fear of putting international characters into this documentation; earlier versions of Perl might not be able to compile it then). we love transparency. 💀
⚖️ COPYRIGHT, LICENSE AND WARRANTY ⚖️
This program is copyright (c) 2006 Baron Schwartz. Feedback and improvements are welcome. 🫶
THIS PROGRAM IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2; OR the Perl Artistic License. On UNIX and similar systems, you can issue man perlgpl or man perlartistic to read these licenses.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA.
Execute innotop and press ! to see this information at any time. yes bestie, the copyright is literally one keypress away. iconic behavior. 💅
👑 AUTHOR 👑
Originally written by Baron Schwartz; currently maintained by Aaron Racine.
🐛 BUGS 🐛
you can report bugs, ask for improvements, and get other help and support at <https://github.com/innotop/innotop>. there are mailing lists, a source code browser, a bug tracker, etc. Please use these instead of contacting the maintainer or author directly, as it makes our job easier and benefits others if the discussions are permanent and public. Of course, if you need to contact us in private, please do. (do it, we don't bite. well. mostly. 🌸)
and that's a wrap on this whole entire man page bestie!! 🎉 this page is from perl v5.20.2, dated 2017-01-23, and it's the INNOTOP(1) manual. you made it to the end of all of it — main character energy fr fr. go run some queries. slay. 💖✨👑🌸
📦 where this page comes from
- ubuntu resolute: mariadb-client 1:11.8.6-5 · GPL-2.0-only
- ubuntu resolute: mariadb-client 1:11.8.6-5ubuntu0.1 · GPL-2.0-only
- ubuntu stonking: mariadb-client 1:11.8.9+ds-4ubuntu2 · GPL-2.0-only
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms