There's a lot of misinformation in this thread, so I'm going to describe best practice for this sort of thing.
1. The client authenticates, and asks to be remembered.
2. The server generates a cryptographically random token of at least 128 bits in length. This token is *never* directly stored server-side.
3. The hash (or, possibly, a slow-hash) of the token is saved in the database along with a time of expiry
4. The non-hashed token is sent to the client as a cookie completely independent of the session cookie
When the client visits the website:
1. The server checks for the presence of the remember-me cookie
2. If the cookie is set, it is hashed and this hash is searched for in the database (and filtered to tokens with expiry times after now)
3. If the user is successfully logged in, the old token is deleted from the database. A new token is generated and sent to the client by the previously-described process
Now for a little bit of explanation.
This process completely isolates the authentication token from the session. If a token is somehow intercepted or discovered by an attacker, it is only usable for a single session. Such tokens should never be allowed to serve as permanent entry points into a user's account.
The token is never directly stored server-side. This confers two benefits. First, these tokens should be considered password-equivalent — if someone manages to steal your table of remember-me tokens, they would be completely unable to use them to log into a user's account. Second, this prevents timing attacks; if you simply looked for matching tokens in your database, an attacker can (shockingly simply) use timing information to guess a user's remember-me token in O(n) time.