At a behavioral level, Observer and Decorator are probably the ones I use the most.
You can't really use design patterns effectively without employing builders. And factories of some sort are inevitable in most relatively complex apps.
Probably the most important thing to know about design patterns is the concept of Inversion of Control - the idea that classes are not manipulated from above, but rather communicate between themselves. Then most of the behavioral patterns become organizations of these communicating entities, and builders become obvious as something needs to tell these things about each other.
To start thinking this way, think of your classes as workers in an office that communicate by interdepartmental memo. Interfaces define the types of 'memos' that an individual can send, and calling an interface is like sending a memo. Having a reference to an interface is like knowing someone's office number, so that you can send them a memo.
If you can wrap your head around this style of design, most of the patterns will be clear and naturally fall out of the code you write. You won't have to study them, they'll just happen.
Understanding and learning design patterns is more about making this shift in thought than it is understanding the actual patterns. Trying to apply "patterns" to procedural-style OO code will just result in messy code that is difficult to work in.
Also, Steve Yegge has a great post on patterns, particularly the bit where he talks about pages 243-256 being the most important pattern. Once you get to the point where you agree with that statement, and not only that, but it's obvious why it's the most important pattern, you probably have a pretty good understanding.