Computer Science BS Journal (CST363) : Week 5

 This marks the 5th week of CST363 and things are going great so far. This week we designed a prescription database, practiced transactions on MySQL as well as practiced some SQL in our homework 3 assignment. I had fun making the database for the prescriptions, I still get a little confused when it comes to the 1:1 or 1:M relationships so I had to go back and review a bit to be sure I was correct. Homework 3 and Lab 15 were pretty straightforward but they were good material to practice what was taught to us thus far.

The web site "Use the Index Luke" has a page on "slow indexes".   https://use-the-index-luke.com/sql/anatomy/slow-indexes

If indexes are supposed to speed up performance of query,  what does the author mean by a slow index? 

    After reading through the article I can conclude a few things. 

  • What is a "slow index"?
    • A slow index is one that exists and is technically used by the query planner, but results in poor performance because it's not optimal for the specific query being executed.
    • These indexes are "slow" not because indexing is inherently bad, but because the wrong index is being used for the query's structure or filtering pattern.
  • Why can an index be slow?
    • Inefficient access paths: If an index only helps partially, the database still has to do a lot of work(like scanning many index entries or doing many lookups).
    • High cardinality and poor selectivity: If an index column has few distinct values, it's not very selective, and the index may not narrow down the result set much, leading to many reads.
    • Not covering enough columns: If the index doesn't include all the columns needed for the query the database must to extra lookups to get data from the table, which can be expensive.
    • Used for sorting or joining but not filtering: Sometimes indexes are used to avoid sorting or help with joins, but they might not reduce the number of rows, so the performance gain is small or even negative.
    • Database optimizer misjudgment: The query planner may mistakenly choose a suboptimal index, believing it's faster, especially when statistics are outdated.
  • Conclusion: "Indexes speed up queries only when they are well-matched to the query's filtering and access pattern". A slow index is a warning sign: the index is used, but poorly. And as the author emphasizes, just using an index isn't enough - it has to be the right index.

Comments

Popular posts from this blog

Computer Science BS Journal: Week 4

Computer Science BS Journal: Week 2

Computer Science BS Journal: Week 5