This isn't perl, its DB, but it happened to occur in perl code and in the monastery so I feel like I can somehow get away with posting it anyway. Apologies to you rabid "perl only" types out there. :-)

So you've spent some time getting your table sorted. You've indexed the important columns and you feel happy. One of your tables stores data about when an event occured, and you need to often find out things like "events in the past 10 minutes". You've indexed the tstamp field so you can query it efficiently and you write a query like this:

SELECT event_id, tstamp FROM events WHERE UNIX_TIME(tstamp) > UNIX_TIME(NOW())-600

The problem (if you havent already seen it) is that this query "blows the index", meaning that the DB can't use the index it has on tstamp to solve it. Why? Because of the UNIX_TIME(tstamp). The index on tstamp is in some internal date format, most likely not on a unix time. So in order to resolve this query the DB has to apply UNIX_TIME(tstamp) to each value in turn, and then compare it to the constant on the right hand side (most DB's will resolve expressions like this at query compile time, or in other words only once). Now its possible you are using a DB with a smarter optimiser, but there is also a good chance you aren't. A simple rewriting of this as

SELECT event_id, tstamp FROM events WHERE tstamp > DATE_SUB(NOW(),INTERVAL 10 MINUTE)

allows the DB to use the index and resolve the query as efficiently as possible. The moral is that indexes on fields are generally useless in a query when the where clause involves functions on those fields and not the fields compared to constants. That and always check how the DB will resolve your query and make sure its doing it in a way that makes sense. :-)

This code is/was in use in a number of places in the monastery. One example has to scan 400k records when it blows the index, and only 3k when it uses it. So that gives you an idea of the difference in performance.

So, don't blow that index dude. :-)