MySQL SQL Performance Tuning: 8 Great Monitoring Practices

MySQL SQL performance tuning

DBAs don’t mind getting the attention of the management, as long as it’s for a positive reason. I mean once in a while, but not all the time; many would still prefer to remain off-radar, quietly ensuring the organization’s databases stay running without a hitch.

Since they have significant accountability in an organization, it is essential for them to beware of all the things that could go south. They can do this by following certain excellent practices for monitoring and MySQL SQL performance tuning, which we will explain in this post.

Best MySQL Database and SQL Monitoring Practices

With these practices, you can avoid being recognized by management for the database outage that took four days to fix, instead of your people skills.

  1. Conduct Regular Health Checks of Your Database

A database administrator knows how important it is to schedule regular health checks for their database. Note that every database has its own maintenance requirements, and that the health checks should be geared toward particular functional needs.

Databases that are non-critical do not require as frequent checks as mission-critical or life-critical databases. A local bookshop’s customer rewarding app failing isn’t as severe as the failure of a missile defense system, for instance.

  • Monitor MySQL Availability

This is perhaps the most essential metric to follow, since the unavailability of the database won’t leave much choice, nor will the other metrics matter until this particular issue is resolved. Use the Run dialog to check availability. You need to type in “ -mysqladmin -h 192.168.1.95 -u root -p” to do so, and initiate diagnostics in case there’s a problem.

  • Check for Unsuccessful Connections & Error Logs

Monitoring the list of unsuccessful connections can slowly but surely help you identify both malicious activity and errors that aren’t as serious (caused by human error like incorrect id\password or misapplied permissions), in the application.

You are likely to get a broader picture in this manner, which will enable you to recognize larger recurring problems so that you can address them appropriately. You can keep track of failed connections by running the following command –

SHOW GLOBAL STATUS LIKE ‘aborted_connects’;

– to know the number of aborted connection attempts on the database in a provided time range.

  • Identify Deadlocks in InnoDB

In MySQL database and SQL, a deadlock takes place when multiple transactions put a lock on a resource required by another transaction. Deadlocks lead to retarded processing, increased timeouts – and unhappy users. Using the query “SHOW ENGINE INNODB STATUS;” will help you find deadlocks and fix them.

  • Observe Configuration Changes

An abrupt decline in performance can be the result of any number of causes. However, checking for any recent configuration changes can help you spot any adversely affecting ones and save you a considerable amount of time.

  • Keep an Eye On the Slow Queries Log

Queries that are slow make the database operate slower as well. This is due to an increase in CPU and memory usage. Assess the Slow Queries log from time to time to know if any queries are taking excessive time to run. You can then proceed towards identifying the root cause and resolving it. 

  • Maintain Visibility to Comprehend the Main Reason Behind Performance Issues

Although regular health checks are important for MySQL SQL performance tuning from the perspective of maintaining high availability, they are not as useful in terms of overall system troubleshooting.

This is because periodic performance concerns may not appear during a routine health check, which is also why a consistent visibility must be established with the MySQL environment.

The quicker you can uncover and fix performance related problems, the fewer the users that will be affected, since downtime will be considerably decreased. 

Setting alerts for critical occurrences can give you the chance to react as quickly as possible, in case a threshold is surpassed. You may set alert thresholds for these typical performance deterioration sources, at least –

  • Substantial deviations from baseline metrics, in terms of performance tuning in SQL MySQL
  • Excessive CPU utilization
  • Query latency
  • Query faults
  • Connection restraints
  • Buffer pool usage
  • Identify and Resolve Performance Issues Quickly

A database monitoring and MySQL SQL performance tuning tool is going to be the best option in nearly every case, so that issues are resolved before they grow into bigger problems.

There are plenty of performance tuning and monitoring tools on the market that come with a broad range of features at varying price ranges. Choosing the right one for your database will depend on your budget and requirements.

As long as you know what to look for in a performance tuning tool, you won’t have many issues in making your selection. Given below are a few features you should consider if you want a tool to perform SQL tuning for MySQL –

  • Scalability
  • Mobile tracking
  • Intuitive User Interface
  • Affordable yet feature-filled
  • Zero connection limitations
  • Different analysis variations, such as
    • Multidimensional workload analysis
    • Alarm source analysis
    • Blocking analysis
  • Smart alarms
  • Historical data monitoring

SQL Performance Tuning: Frequent Questions about Indexes

SQL performance tuning

A database is a piece of software operating on a computer, which means it is dependent and likely to face the same limitations as other software present on that computer. In other words, it will only be able to process as much data as the hardware can handle.

One of the best ways to speed up queries is to perform SQL performance tuning. In this post, we will answer some of the most frequent questions involving databases and indexes.

What is Indexing in SQL Query Optimization?

Indexing is one of the first things you may have come across while learning the ropes of your database. It is a wonderful tool that enables users to enhance the efficiency of their database. However, bear in mind that not every database requires indexing, and not all indexes are helpful in SQL performance tuning.

Let’s learn more about indexing: what it is and how it helps in enhancing database performance.

How do Indexes Affect SQL Query Performance?

An Index can locate data swiftly without having to go through each row in the table. This saves plenty of time! 

Certain data columns are required before you can create an index. These are –

  • The Search Key which holds a duplicate of the primary key
  • The Data Reference which has a set of pointers

All of these constitute the structure of one index. To understand how an index works, let us take an example. Suppose you need to look for a bit of data in your database. Rather than scour every line yourself, you make the computer search each row till it locates the information. Remember that the search is bound to take much longer if the requisite information is located at the end. Fortunately, you have the option to sort alphabetically to shorten the length of such queries.

What are the Types of Database Indexes?

Database indexes are of two kinds –

Clustered indexes – These arrange data using the primary key. The reason behind using a clustered index is to make sure the primary key is saved in ascending order. This is the same order in which the table stores memory.

A clustered index is automatically created when the primary key is set, which helps in SQL tuning for Oracle in the long run as well.

Non-clustered indexes – A non-clustered index is a data structure that boosts data fetching speed. It is different from clustered indexes, as they are made by data analysts or developers.

When and How Should We Use Indexes?

Since indexes are intended to accelerate database performance, you should apply them whenever you think they can simplify the use of the database. Although smaller databases may not have several opportunities to use indexes, they are likely to see the benefits of indexing as they grow into larger databases. 

You can make sure your indexes keep performing well, if you test run a set of queries on your database first. Clock the time those queries take to execute and begin creating your indexes after that. Keep rerunning these ‘tests’ for continuous improvements.

Conclusion

Indexing has its challenges, the biggest one being determining the best ones for every table.

For instance, heaps require clustered indexes because searching for a record in a heap table is comparable to finding a needle in a haystack: it’s inefficient and time-consuming, thanks to the heap’s unordered structure.

On the other hand, locating data is simpler and faster from a table that contains a proper clustered index, just like finding a name in a list that’s alphabetically ordered. DBAs, therefore, recommend that every SQL table contains a proper clustered index. Now that you know how indexes work and how they can optimize database performance, you should be able to use them to reduce query times substantially. If you would like more tips on how to use indexing, or you need a SQL query optimization tool for your database, let our experts know!

Improve SQL Queries & Database for Better Efficiency: Part 2

This is the second blog in our two-part series to explain the best ways to optimize your database, which is best done by enhancing the SQL queries being used. Without much ado, let’s pick up where we left off –

Give Preference to WHERE, instead of HAVING (when defining filters)

A query is efficient when it saves resources by fetching only what’s needed from the database. According to the Order of Operations defined in SQL, WHERE queries are calculated before HAVING statements.

Therefore, it is advisable to give preference to WHERE over HAVING when the goal is to filter a query on the basis of conditions for greater efficiency. 

For instance, let us suppose a hundred sales have been made during the year 2019, and a user wishes to put in a query to determine what the number of sales was for the same time period. They may write something like this:

SELECT Clients.ClientID, Clients.Name, Count(Sales.SalesID)

FROM Clients

   INNER JOIN Sales

   ON Clients.ClientID = Sales.ClientID

GROUP BY Clients.ClientID, Clients.Name

HAVING Sales.LastSaleDate BETWEEN #1/1/2019# AND #12/31/2019#

This statement would return at least a thousand sales records from the Sales table, then filter these thousand records to find the hundred records generated in the year 2019, and lastly, tally the data in the dataset.

If we compare the above with the same instance using the WHERE clause instead, there is a limit placed on the number of records fetched:

SELECT Clients.ClientID, Clients.Name, Count(Sales.SalesID)

FROM Clients

  INNER JOIN Sales

  ON Clients.ClientID = Sales.CustomerID

WHERE Sales.LastSaleDate BETWEEN #1/1/2019# AND #12/31/2019#

GROUP BY Clients.ClientID, Clients.Name

This statement would return the hundred records from the year 2019, after which it would count the records in the dataset, thereby getting rid of the first step in the HAVING clause.

Keep wildcards strictly at the end of a statement

A wildcard creates the largest search possible when looking for plaintext information like names or designations. However, the wider a search, the less efficient it is, and a leading wildcard worsen the performance – particularly when it’s used with an ending wildcard.

That’s because the database has to find every single record that remotely matches the selected field. Take this query to fetch cities beginning with ‘Ch’, for instance:

SELECT Cities FROM Clients

WHERE Cities LIKE ‘%Ch%’

This statement will not just fetch the expected results of Chicago, Chester, and Chelsea, but will also return unintended results, like Richardson, Canal Winchester, and Cannon Beach.

A more productive statement would be:

SELECT Cities FROM Clients

WHERE Cities LIKE ‘Ch%’

This query will lead only to the expected results of Chicago, Chester, and Chelsea.

Use LIMIT to sample query results

The use of a LIMIT query will make sure the results of new SQL queries are relevant and desirable. As the name suggests, its function is to limit the quantity of records to the number mentioned, saving a lot of resources in the process.

Considering the 2019 sales query from above, let us suppose a limit of 15 records:

SELECT Clients.ClientID, Clients.Name, Count(Sales.SalesID)

FROM Clients

  INNER JOIN Sales

  ON Clients.ClientID = Sales.ClientID

WHERE Sales.LastSaleDate BETWEEN #1/1/2019# AND #12/31/2019#

GROUP BY Clients.ClientID, Clients.Name

LIMIT 15

The results will indicate if the data set is worth using or not.

Adjust Your Timing a Bit

If you’re looking to minimize the impact of your analytical queries on the production database, consult with an Oracle Database Administrator regarding the scheduling of your SQL queries so that they can be run during off-peak hours.

Specific hours when there are fewest concurrent users, generally in the middle of the night, should be chosen to run such resource consuming queries. If your SQL queries are more likely to include the following criteria, consider running it during off-peak timings:

  • Selecting from huge tables (where there are over a million records)
  • Queries with Cartesian or Cross Joins
  • Looping queries
  • SELECT DISTINCT queries
  • Subqueries that are nested
  • Search queries involving wildcards in long text or memo areas
  • Numerous schema statements

Query with Confidence!

Keeping these and other SQL tips into consideration will certainly enable you to construct efficient, smart queries that will operate swiftly and fetch your team the game-changing insights it needs.

Improve SQL Queries & Database for Better Efficiency: Part 1

SQL is probably the most popular and powerful means to handle data, but sometimes you need actionable advice to unleash its power and make the most of such a robust language.

In case you’re operating in the absence of a data warehouse or a segregated analytical database for assessment, you may be able to gain updated information only from the live production database.

However, optimization and tuning are very important while writing queries for an Oracle database, especially a production database. In this two-part series, we will cover eight of the most useful ways to supercharge your database by enhancing the SQL queries used.

Make Tuning Your SQL Queries Easy Using these Tips

Consider the following ways to improve the performance of your database –

Clarify the organization’s requirements first

There are certain practices that benefit not just the users optimizing SQL queries but also the organization in general, such as:

  • Determining relevant stakeholders
  • Concentrate on business implications
  • Structuralize the discussion for the ideal specifications
  • Ask the right questions (Who? What? Where? When? Why?)
  • Make the requirements as specific as possible, and confirm those with the stakeholders.

Limit the scope of the SELECT query

A majority of SQL professionals have a bad habit of using SELECT * as a shorthand and end up fetching all available information from a table. If the table in question has numerous rows and fields, this takes up a lot of Oracle database and SQL resources by returning plenty of unrequired data.

The use of the SELECT statement must be done in a way that makes the database fetch only the data required to fulfill the business requirements. Consider the following instance, where the organization’s requirements request postal addresses for clients –

The query SELECT * from Clients is inefficient as it might bring in other information also fed in the client table that isn’t needed here. Instead, a query like this would only fetch the data necessary as per the requirements.

SELECT Name, Address, City, State, Zip

FROM Clients

Refrain from Using SELECT DISTINCT

Eliminating redundant information from a query is easy with SELECT DISTINCT, which GROUPs certain fields in the statement to return distinct results. Achieving this goal, however, requires substantial processing power. Moreover, the grouping of data may not be accurate, which is why you must avoid using this ‘trick’ altogether.

Take this example, for instance –

SELECT DISTINCT Name, City, State

FROM Clients

This statement doesn’t account for several people in the same city or state having the same name. Common names like John or Jane will be grouped together, leading to an incorrect quantity of records. Bigger databases that contain numerous Johns and Janes will not benefit from this query.

In its place, try to use something like this –

SELECT Name, Address, City, State, Zip

FROM Customers

By increasing the fields, unique records will be fetched without the use of SELECT DISTINCT. The database also wouldn’t have to cluster any fields, and the result set would be accurate.

Use INNER JOIN to Make a Join, not WHERE

Some SQL professionals choose WHERE clauses for joining, like in the example below –

SELECT Clients.ClientID, Clients.Name, Sales.LastSaleDate

FROM Clients, Sales

WHERE Clients.ClientID = Sales.ClientID

This kind of join creates a Cartesian Join, also known as Cross Join or a Cartesian Product. It involves the creation of every potential combination of the variables. If we suppose the table in the above example contains a thousand clients with a thousand total sales, the statement would generate a million results in the first go, after which it would filter those results to fetch records where ClientID is correctly joined.

It’s an unnecessary waste of database resources since the database ends up doing over a hundred times more work than is actually needed. Moreover, Cartesian Joins are particularly cumbersome in large-scale databases because it is likely to fetch billions or trillions of results.

Therefore, it becomes essential to use something like an INNER JOIN instead, in order to avoid the creation of a Cartesian Join –

SELECT Clients.ClientID, Clients.Name, Sales.LastSaleDate

FROM Clients

   INNER JOIN Sales

   ON Clients.ClientID = Sales.ClientID

In this case, the database would only fetch a thousand records where ClientID matches. Certain DBMSs identify WHERE joins and run them as INNER JOINs on their own accord, which is why they won’t show any change in performance between a WHERE and INNER JOIN. 

What Optimization in SQL is, and Why It’s Necessary for DBAs

SQL statements or queries are designed to retrieve information from the database. A user can achieve the same results through optimization in SQL; using a tuned query is especially useful from an execution perspective. 

Tuning a database is a vital step in organizing and accessing the information in a database. Performance tuning in SQL requires streamlining and homogenizing the environment of a database and the files in it. This simplifies the way users access data in a big way. 

Why Companies Need to Consider Optimization in SQL

Several organizations own databases, but not all of them hire IT staff knowledgeable in the ways of optimization in SQL. Only professionals who have tuning skills and experience along with insider information about the working of databases should do this. 

In case your company has a database but it hasn’t undergone performance tuning, you might encounter inadequate responses to queries and face unnecessary complications when handling data. Don’t let your efficiency get affected because of something avoidable like this! 

Performance Tuning in SQL: What It Involves

Tasks related to performance tuning include optimization in SQL database, creating and managing indexes, and other related tasks to maintain or improve database performance. The goal of MySQL query optimization is to increase the speed and brevity of query responses and to simplify data retrieval. 

Let’s look at three major reasons why companies need to take performance tuning and seriously – 

1. To enhance the rate of data fetching options

If your database lacks optimization, then fetching data can get slower with increasing data loads. Optimizing queries enables users to create indexes and eradicate issues that may be slowing down data retrieval. After all, it can get quite frustrating for your employees to wait for the database to perform its operations, which can pass on to customers forced to wait for the same.

2. To refrain from coding loops

Making your database go through a coding loop is akin to hammering it repeatedly. That’s because the same query is executed several times when it is placed in a loop. However, once you remove the query from the loop, you will experience a definite surge in performance because the query is run only once rather than going through multiple iterations. 

3. To increase the performance of your SQL statements 

Query tuning in SQL includes changing previous query patterns and habits that were affecting the speed of data storage and retrieval. For example, the use of SELECT is reduced by opting for separate column declaration and eliminating correlated subqueries. Queries are also simplified by obviating temporary tables at times, aside from many other techniques of optimization in SQL

Your database will be able to manage much more data after the application of all these improvements as these will increase its efficiency, making it scalable as well. Once your database has scalability, it also overcomes lower performance and ensures user satisfaction in terms of experience. 
If you require professional tools to manage MySQL query optimization and tuning, then Tosska can help you. Tosska provides highly intuitive tools that can simplify query tuning beyond your imagination, and it does this with the help of innovative AI technologies. Contact us today to learn more about our range of query optimization products and services.

How You Need Tuning to Improve MySQL Database Performance

SQL performance tuning is about saving you a great deal of money by improving various aspects of database management. Be it changing inefficient queries or replacing unnecessarily large indexes, tuning your database can really help you regulate your expenses.  

SQL tuning will not only improve MySQL database performance, but it will also help you save multiple resources, whether you operate your database servers on-premises or migrate your data over to the cloud.

Performance Tuning – More Than Just Optimization of SQL Queries

A majority of database professionals mostly focus on ensuring uptime by keeping tabs on the allocation of resources such as storage and memory. These formed a sizable portion of database management until companies started moving their databases to enormous cloud resources like AWS and Azure. 

This gave importance to other aspects like performance tuning in SQL, which DBAs work on once they ensure that things are running somewhat smoothly. However, a lot of database professionals may have to tweak a SQL Server that they aren’t familiar with, and there’s not much help available for such instances. 

Identifying Problem Areas During Performance Tuning

It can get intensive trying to figure out all the issues and resolving them one after another. At first, your problems may not even involve the optimization of SQL queries, and you may begin your search at the user/session-level. 

What some professionals do at this point is, they listen to the users and ask questions such as – 

  • Are there any specific times when the application slows down, for example, when they create an extra ticket or open an active one?
  • Which data takes excessive time to render?
  • How long does saving a record take? (a specific answer may be preferable)

Improve MySQL Database Performance in SQL Server with These Tools

Fortunately, SQL Server has multiple features that can help you improve MySQL database performance with greater convenience. Some of them are – 

Plan Guides

Plan guides enable you to adjust the way SQL Server executes a query, affecting performance. These are especially useful in case of queries written by another vendor, where some experts may not be willing to change them right away, as you can add a query hint to influence its operation. 

However, plan guides may get obsolete over time because the scenario may change after a while but they cannot. To overcome this, make a note of reviewing them from time to time. 

Query Store

This feature helps in the optimization of SQL queries too. It allows the user to determine which queries are taking up the most resources, and then tune them. Apparently, the Query Store feature is not enabled in some SQL databases because the user rarely needs it at first, but enabling it is easy.

Some DBAs are not aware of the Query Store, while others know of it but haven’t explored it enough, so the feature may as well be disabled. They can begin its use once they know how it works so that they can analyze various performance fluctuations caused because of modifications in the query plan.

Database Engine Tuning Advisor

This function examines workflows and suggests indexes or other strategies to improve MySQL database performance. On the other hand, don’t run this tool until your database has sufficient data stored, as the recommendations are more productive at that point. 

It won’t be as useful for a newer application that has, say, only a thousand rows in its tables, than after the app has expanded a bit.

Why DBA Tuning for Oracle SQL Query is Crucial in Databases

SQL tuning is an extensive topic in itself that deserves coverage in books dedicated to stored programming. This is because it is considered as a vital skill for those who create stored programs in MySQL or Oracle.

There are several other reasons as well, which we will discuss in this blog. 

DBA Tuning of SQL Queries – Why They are Important

Take a look at some reasons why SQL tuning is so important – 

  • Those who are not convinced about the importance of DBA tuning need to remember a simple fact that SQL statement execution takes up the most time when stored program execution time is analyzed. 
  • Additionally, a database that is insufficiently tuned or not tuned at all is tremendously slow by comparison. 
  • An untuned database cannot scale well with the growth in data volumes. This means that although your program appears to perform acceptably well at the moment, chances are, it will face serious performance issues in the future without proper tuning.

Database Query Optimization – An Informative Example

Given below is an example that explains the necessity of SQL query tuning in overall system performance. Let us consider a query that performs a straightforward join between two tables:

SELECT sum(sale_value),x.sales_id

FROM tx_10000 x,ty_10000 y

 WHERE x.sales_id=y.sales_id

GROUP by x.sales_id;

As data gets collected every day, the size of the tables also increases. At first, there may not be any visible change in performance, but that will change just after some days. After about seven days, the application will become nearly inoperable if the query plan is not correctly selected by the database SQL optimizer, and that’s when the need for a DBA SQL tuning is realized. 

On closer analysis, the DBA shall uncover a proportional relationship between table size and elapsed time. It is also observed that along with the worsening query performance as the tables expand, there is also an acceleration in the rate of increase.

The DBA may project the estimated time to be around twenty hours as the size of the tables approaches their peak sizes, around a million rows, which is truly a poor performance trend. 

The issue and solution both seem obvious once the SQL statements used in the application are assessed, and the solution is to perform database query optimization by supporting the join with an index, which can be created in this manner: 

CREATE INDEX i_ty_1000 ON ty_1000 (sales_id);

This brings a remarkable improvement in the performance trend, with over 99 percent decrease in elapsed time for the mentioned query. Furthermore, the database is over a hundred times quicker and it can now scale well with the raise in table data volumes. 

In Conclusion

Such dramatic changes cannot be achieved through hardware upgrades, stored program tuning, or any amount of server enhancement. Even if any of these were to be carried out, it wouldn’t make much of a difference in the long run. 

This is because the rapid degradation would ultimately quash any performance improvements attained by other techniques. This is why DBA tuning is more important than any other mode of optimization and should be performed first. 

Oracle or MySQL SQL query tuning is the most essential aspect of application performance in general, so make sure that SQL is tuned before any other sort of optimization activities are carried out.

Tosska SQL Tuning Expert (TSEM™) for MySQL® – System Requirements

Before installing Tosska SQL Tuning Expert (TSEM™) for MySQL®, please make sure your system meets the following minimum hardware and software requirements:
 

CPU 1.8 GHz Processor
Memory 2 GB of RAM minimum, 4 GB of RAM recommended
Hard Disk Space 200 MB of disk space for 32-bit installation
400 MB of disk space for 64-bit installation
Operating System Microsoft Windows® 7 32-bit and 64-bit
Microsoft Windows® 10 32-bit and 64-bit
.NET Framework Microsoft .NET Framework 4.5.2
Database Server MySQL database 5.6 or higher

Oracle Database and SQL: Tips for MySQL Database Performance Tuning

Until now we have learned a lot about Oracle database and SQL performance tuning. Now, let’s discuss MySQL database performance tuning. Just like any other relational database, MySQL could also be a nightmare to many. It can crawl to a halt at a moment’s notice and in the next moment, you will find it leaving your apps in the lurch and your business on the line. The fact is, regular errors underlie most MySQL performance issues. 

To ensure your MySQL server bustles along at great speed, providing consistent and stable performance, it’s imperative to eradicate such mistakes that are often confused by some subtlety in your configuration trap or workload. Just like any other performance tuning tips for Oracle database and SQL, MySQL too has some of its own performance tuning techniques that we have described in this blog. Let’s get started without wasting more words-

Oracle Database and SQL- Know How to Tune MySQL Database Performance

Fortunately, many MySQL performance problems have similar solutions which make both tuning MySQL and troubleshooting a manageable task. 

Here are a few tips for getting great performance out of MySQL.

Tip 1# Profile Your Workload

The best way you can understand how your server invests its time is to profile its workload. By doing so you could expose the most expensive queries for further tuning. When you issue a query against the server, you don’t have to care much about anything else except how quickly it completes. Therefore, time is the most crucial metric to consider here. 

The most significant way of profiling your workload is using a tool such as MySQL Enterprise Monitor’s query analyzer. Such a tool is meant to capture queries that are executed by the server. Furthermore, it returns a table of tasks sorted by decreasing order of response time, quickly bubbling up the most time-consuming and expensive jobs to the top so that you can find where you need to put your efforts. Workload-profiling tools group identical queries together that allow you to find slow queries as well as the queries that are fast but executed multiple times. 

Tip 2# Recognize the Four Basic Resources

For functioning, a database server requires four basic resources- Network, CPU, Disk, and memory. If any of these resources are weak, overloaded, or erratic, then the database server is most likely to perform badly. Recognizing these fundamental resources is crucial in two specific areas: selecting troubleshooting and hardware issues. 

While you choose hardware for MySQL, you must ensure the components perform well all around. Just as essential, ensure to balance them reasonably well against each other. Often, businesses choose servers having fast CPUs and disks but that are starved for memory. In some cases, adding memory is a cheap way of enhancing performance by order of magnitude, specifically on workloads that are disk-bound. This might seem counterintuitive, but in various cases, disks are overused as there isn’t sufficient memory to hold the server’s working set of data. 

Another good example of this perspective relates to CPUs. In most conditions, MySQL performs well with fast CPUs as every query runs in a single thread and can’t be parallelized across CPUs. 

During troubleshooting, examine the performance and utilization of all the four resources with much care and determine whether they are performing badly or are simply being asked to execute excessive work. This knowledge can help solve issues instantly. 

Tip 3# Don’t use MySQL as a Queue

Queues and queue-like access patterns can sneak into your application without even letting you know. For instance, if you set the status of an item so that a specific work process can claim it before working on it, then you are ignorantly formulating a queue. Marking emails as unsent, sending them and then remarking them as sent in a common example. 

Queues create problems for two big reasons: they serialize your workload which prevents tasks from being done in parallel, and they mostly result in a table that includes work in process as well as earlier data from jobs that were executed long ago. Both add concealment to the application and load to MySQL. 

Tip 4# Firstly Filter Results by the Cheapest 

The best way of optimizing MySQL is to do imprecise, cheap work first, then the precise and hard work on the smaller that will result in a set of data. 

For instance, consider you are searching for something within an assigned radius of a geographical point. The initial tool in many programmers’ toolbox is the great-circle (Haversine) formula. This will compute the distance along the sphere’s surface. The trouble with this technique is that the formula needs a variety of operations related to trigonometry, which are very intensive toward the CPU. Great-circle calculations tend to perform slowly and make the machine’s CPU utilization skyrocket. 

Before you implement the great-circle formula, cut down your records to a small subset of the total, and scrape the resulting set to a precise circle. A square that comprises the circle either precisely or precisely is a simple way of doing this. That way, the world outside the square never gets hit with all those expensive trig functions. 

Tip 5# Understand the Two Scalability Death Traps

Scalability isn’t as fuzzy as you may think. In fact, there are explicit mathematical definitions of scalability that are defined as equations. Such equations emphasize why systems don’t scale and why they should. Consider the Universal Scalability Law, a definition that is convenient in expressing and quantifying a system’s scalability qualities. It explains scaling issues in terms of two elementary costs: crosstalk and serialization. 

Parallel processes that must hold for something serialized to take place are inherently limited in their scalability. Similarly, if such processes are required to chat with each other all the time for coordinating their work, they restrict each other. If you avoid crosstalk and serialization, your application could scale much better.