Usually, when your database runs slower for an extended period, the culprit is more often than not a "bad" query. That is to say, a query that is not fully optimized, poorly written, or gives users the ability to fetch an unlimited number of rows from the database. We can alleviate some pain by throwing more resources at the server, but this is really a short term fix and doe not address the underlying issue. The best course of action is to identify and fix the problem query or queries, which shouldn't be too difficult, given some time and effort. Of course, the first step is to identify which query or queries is/are the stalwarts. There are a few ways to do that, depending on your specific database type. Today's blog will highlight a few strategies for MySQL.
In last week's blog, we learned about the ramifications of poor indexing, as well as how to choose which columns to include as part of a clustered index. In this article, we'll cover how the same indexes that provide better performance for some operations, can add overhead for others.
It is common knowledge that judicious use of indexes can help SELECT queries execute significantly faster. This can tempt some database admins (DBAs) to try to milk as much performance gains as possible by adding indexes to every column that might possibly be included in a query. The downside to adding indexes to a table is that they affect the performance of writes. Moreover, improperly created indexes can even adversely affect SELECT queries! Any table configuration where performance suffers due to excessive, improper, or missing indexes is considered to be poor indexing. In today's blog, we'll learn about the ramifications of poor indexing, as well as cover how to choose which columns to include as part of a clustered index.
Databases play a central role in of most business processes and applications. As IT infrastructures become more diverse and sophisticated, it becomes increasingly important to be able to nip database issues in the bud. In simpler times, one or more database administrators (DBAs) could resolve issues manually as they came up in true fire fighter fashion. Today, that approach is almost certainly doomed to fail.
Smart DBAs rely on database monitoring to not only pinpoint trouble quickly, but even to predict future issues before they cause real problems. In this article, we'll examine what database monitors do. In up-coming installments we'll learn more about how they work and explore some best practices for using monitoring software.
In last week's blog we learned about the potential uses and advantages to utilizing Database Partitioning when working with large data sets. In today's follow-up, we'll create a MySQL partition in Navicat for MySQL using the HASH partitioning criteria.
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)
