ClusterControl Schema Advisors: Why, When, How?

If you’re a database administrator, your database schema is probably one of the primary things you keep a watchful eye on. However, database schema design consists of many different things, and as a database administrator you’re probably busy enough as it is. That’s why there are tools that help you automate your database processes with ease – one of them is ClusterControl.

ClusterControl offers many unique features including backup management, monitoring and alerting, deployment, scaling, upgrades and patches, security and compliance, configuration management, performance management, and more. One of those features are performance advisors: ClusterControl’s performance advisors can be split into a few different categories because they accomplish different tasks: some of them monitor your performance schema, some of them monitor indexes, some of them monitor the replication configuration, etc.: in this blog post, we are going to look into schema advisors available in ClusterControl.

To observe the list of advisors available in ClusterControl, log into the system, head over to Performance -> Advisors:

You will be able to see a bunch of performance advisors. These advisors, as you can see, can be categorized into a couple of different categories: all advisors would show all of the advisors available in ClusterControl, MySQL would show only advisors relevant to MySQL, security would show security-based advisors, replication would show advisors relevant to the replication of your database nodes, innodb would obviously take care of InnoDB, etc.: we are going to dig into the schema advisors available in ClusterControl.

Schema Advisors

Severalnines’ ClusterControl, at the time of writing, has only one schema advisor, but that advisor is extremely important too and shouldn’t be overlooked in any scenario. Take a look, can you guess why?

In this case, schema advisors are checking for tables with duplicate indexes. We should be glad that ClusterControl has found no duplicate indexes inside of our tables – here’s why:

• We generally use indexes when we want to improve our SELECT query performance keeping in mind that indexes slow down INSERT, DELETE, and UPDATE queries.

• Database management systems (such as MySQL) generally does not protect us from making mistakes such as adding multiple indexes on the same table:

  CREATE TABLE `demo_table` (
  `id` INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `column_2` VARCHAR(10) NOT NULL,
  `column_3` VARCHAR(10) NOT NULL,
  INDEX(id),
  UNIQUE(id)
  );

  In this case, you might think that the ID would be implemented as a primary key, with a B-tree and a unique index on it, however, that’s not the case: MySQL implements all PRIMARY KEY constraints with indexes, and since we have specified an INDEX and a UNIQUE INDEX on it, that would add two more indexes on the same column! See how that might be a problem?

• Indexes, as already stated, slow down INSERT, DELETE, and UPDATE queries – if you have unnecessary indexes (say, two or more on the same column) and you want to execute one or more of them against your database instances, your queries will be unnecessarily slow.

Editing and Deleting Schema Advisors

With that being said, you probably already have an idea how schema advisors provided by ClusterControl can solve your database issues – however, what’s also worth mentioning is that all of the advisors (including schema advisors) can also be edited or deleted – when editing those, bear in mind that you will probably need some knowledge of javascript and also know your way around a couple of SQL queries:

These kinds of scripts, as you can see above them, can be compiled, disabled or scheduled as well: want to run them at specific times (want to run them at specific hours? Minutes? Days? Months? Weekdays? No problem, ClusterControl has you covered here too!):
 

Isn’t that convenient?

Schema advisors (in this case, a duplicate index advisor), would be very useful when you know that indexes are used by a specific database instance, but not sure how many of them are absolutely necessary – do you have to use that index on the column A? Why is there a PRIMARY KEY? Do you really need a UNIQUE INDEX? Etc.

Make sure to give ClusterControl a try today – it can not only solve your index-related problems, but also help you in regards to backing up your data, monitoring performance, also recovering and even automatically repairing your data! Aside from that, ClusterControl also has a command line client (CLI) that is automatically integrated and synchronized with the GUI allowing you to use the CLI to its fullest extent – deployment, configuration and management while using the GUI to achieve your monitoring and troubleshooting goals.