Форум пользователей MySQL

Чтобы добиться такого эффекта, нужно следующее:

1. Таблица должна иметь уникальный ключ на столбце, который должен
хранить уникальные значения, т.е.

CREATE TABLE t (
    email VARCHAR(255)  CHARACTER SET latin1,
    UNIQUE KEY (email)
);

Если важна производительность, то лучше сделать индекс не по всему
столбцу, а по его части; при этом стоит задуматься, сколько символов
достаточно, чтобы считать данную запись уникальной. Например, если
достаточно 15 символов:
UNIQUE KEY(email(15))

Если Вы собираетесь хранить именно e-mail'ы, то рекумендую использовать
для соотв. столбца кодировку latin1 - так сэкономите место на диске и
память для индекса, поскольку нелатинские символы Вам все равно не
понадобятся.

2. При заполнении вашей таблицы используйте конструкцию INSERT IGNORE:

INSERT IGNORE INTO t (email) VALUES ('user@host.ru')

Модификатор IGNORE предписывает игнорировать запись при совпадающем значении уникального ключа, и Вы как раз добьетесь того, что нужно.

Да, конечно.
Более того, можно иметь в одной таблице сколько угодно уникальных ключей.

Специальных встроенных средств конкретно для паролей нет.
Тем не менее, имеющийся инструментарий позволяет весьма с ними работать: например, можно хранить пароли в виде в виде MD5-хэша. Для этого в таблице под пароли выделяется столбец типа CHAR(32) (MD5-ключ всегда имеет длину 32 символа, поэтому в данном случае лучше всего подходит именно тип CHAR).
Как в PHP, так и  в MySQL в современных версий имеется функция md5().

При проверке авторизации просто будете сравнивать хэш введеного пароля со значением, хранящимся в таблице для данного пользователя.

Учтите, что недавно в MD5 нашли дубликаты:
http://ru.wikipedia.org/wiki/MD5
http://eprint.iacr.org/2006/105
но Вам вряд ли придется с этим столкнуться.

LazY написал:

Если Вы собираетесь хранить именно e-mail'ы, то рекумендую использовать
для соотв. столбца кодировку latin1 - так сэкономите место на диске и
память для индекса, поскольку нелатинские символы Вам все равно не
понадобятся.

Это неверно и лучше на это не полагатся никогда.
RFC-822 не накладывает никаких ограничений на набор возможных символов в адресе электронной почты. Более того, в нем возможны даже комментарии, не помню точного примера, но что то типа такого:

<vasya_"да, это мой email"_pupkin@васин.домен>

- это корректный адрес электронной почты с точки зрения RFC.

другое дело, что это никто пока не использует (разве что в локальных корпоративных почтовых системах), но я бы не стал зарекаться от того, что это случится

Shopen написал:

Это неверно и лучше на это не полагатся никогда.
RFC-822 не накладывает никаких ограничений на набор возможных символов в адресе электронной почты. Более того, в нем возможны даже комментарии, не помню точного примера, но что то типа такого:

<vasya_"да, это мой email"_pupkin@васин.домен>

- это корректный адрес электронной почты с точки зрения RFC.

другое дело, что это никто пока не использует (разве что в локальных корпоративных почтовых системах), но я бы не стал зарекаться от того, что это случится

Даже если такой адрес будет, все равно непонятно в какой кодировке его хранить. В UTF8? Я не видел пока стандарта, в котором указано, какую кодировку должен понимать DNS, например. Так, что такие email адреса все равно приведут к проблемам при их появлении, придется обрабатывать особым образом.

Или были бы домены БНБЙЮ.ПС (вместо вовка.ру). При проектировании базы учесть те стандарты, которых нет - практически невозможно. Хвататься за голову будут те, у кого такие адреса, так как с ними работать не будет ничего несколько лет, кроме, возможно, случайных совпадений. Большинство современных веб-приложений сочтут такие адреса невалидными.

Таблицу с email-адресами можно конечно сделать UTF8 (ведь email может быть и на японском), но боюсь одно это не поможет.

С помощью php-функции mysql_affected_rows()  (или SQL-функции ROW_COUNT()) Вы можете узнать сколько строк реально изменилось. Будет 1 - если вставлена новая запись или 0 - если дубликат. Перед добавлением можно проверить наличие записи с помощью SELECT.