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.
Any time that you categorize data into different types, the need to convert from one data type to another is inevitable. Off the top of my head, a common use case is to process variables that were passed in from a web form via a query parameter or POST request body. Serializing data in order to send it across the network tends to coerce all variables into strings. As such, they often need to be converted into a more appropriate data type, such as a number, date, or what-have-you.
- 2025 (1)
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)
