risks

This is not the usual "It's your responsibility" stuff. Please read through.

common_schema is a database schema. It includes routines, views and tables. The risks of using this schema are those affected by issuing queries against its views or routines.

In particular, most of the views rely on INFORMATION_SCHEMA views.

MySQL's INFORMATION_SCHEMA views are not all equal. Some are pretty lightweight (like PROCESSLIST); some take a bit more time to evaluate (like GLOBAL_STATUS) but do not impose locks affecting your data.

Some views, however, require getting metadata for tables, and in fact, require metadata for all tables at once. First and foremost: the TABLES table, but also COLUMNS, STATISTICS etc. Performing even the simplest query on one of these views may cause, in extreme cases, lockdown of your database for long minutes. The author has also witnessed databases crash because of queries on such tables. See also: Making changes to many tables at once, How to tell when using INFORMATION_SCHEMA might crash your database. Consider setting innodb_stats_on_metadata=0 as suggested in Solving INFORMATION_SCHEMA slowness.

It is safer to perform such heavyweight queries on a replicating slave. A slave may actually sustain less "damage" from these queries due to its single-threaded writing mode, making for less contention on table locks. At least this is the author's experience; no guarantees made.

The good news is that those views relying on heavyweight INFORMATION_SCHEMA tables are those you don't mind running on the slave, or on an offline machine. These views usually analyze your table structure, data size, keys, AUTO_INCREMENT columns, etc. They don't have anything in particular for monitoring a live, running server. Some of these views don't actually require data to work on, just a schema.

Examples of common_schema views which rely on heavyweight INFORMATION_SCHEMA tables:

The list above may change, or may not reflect the actual state of views & functions.

common_schema views which are lightweight are the various process, security, monitoring, InnoDB plugin and Percona Server views.

Of course, just as would be able to drop your database being a super user, you could also use common_schema to execute destructive queries. Many routines support the @common_schema_dryrun user variable; use it (set it to 1) if you're not sure about expected results.

You should also note that "common_schema" is hard coded into the distribution files; if you have a schema after the same name, make sure to change "common_schema" in the distribution file.

And, it's your responsibility. By using common_schema, your agree to its license:

LICENSE

common_schema is released under the GPL license.
common_schema - DBA's Framework for MySQL
Copyright (C) 2011-2013, Shlomi Noach

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; either version 2, or (at your option)
any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

A copy of the GNU General Public License is available at
http://www.gnu.org/licenses/

AUTHOR

Shlomi Noach
 
common_schema documentation