在MYSQL中索引電子郵件地址的最佳方法是什麼

Question

我有一個包含數百萬電子郵件ID記錄的註冊表。電子郵件ID是獨一無二的。爲了進行身份驗證，使用asp.net將它們編入索引並獲取它們的最佳方法是什麼？我的意思是我應該將電子郵件ID列定義爲聚集的唯一索引而不是UNIQUE？

Answer 1

當你有一個可變長度的文本輸入，如e-mail或地址，但你希望他們是唯一的，則標準方法是指數的哈希那個價值。

原因：散列是固定長度的，並且您避免了超出索引長度的文本數據的問題。

根據您的意見，你有看起來像這樣的表（我故意省略密碼和手機號碼）：

create table users (
    user_id int not null unsigned auto_increment, 
    first_name varchar(255) not null, 
    surname varchar(255) default null, 
    email varchar(255) not null, 
    primary key(id) 
) engine = innodb; 

我會改變該表，並添加包含電子郵件散列的字段。我會通過觸發器保持這一點，以便您可以專注於獲取有效數據，而不用擔心創建哈希。爲此，該字段將爲binary(20)，因爲它將包含原始散列並佔用20個字節。既然我們想通過觸發來維護它，那麼我們需要使該字段可爲空且唯一。注意：你可以把它binary(40)

表：

create table users (
    user_id int not null unsigned auto_increment, 
    email_hash binary(20) default null, -- this is the field in question 
    first_name varchar(255) not null, 
    surname varchar(255) default null, 
    email varchar(255) not null, 
    primary key(id), 
    unique(email_hash) -- this is the unique index over the hash 
) engine = innodb; 

，我們現在需要的是一個觸發器，它與電子郵件哈希交易。我將介紹如何在插入前創建維護此信息的觸發器。類似的邏輯適用於更新表格：

DELIMITER $$ 

CREATE TRIGGER users_before_insert BEFORE INSERT ON `users` 

FOR EACH ROW BEGIN 
    SET NEW.email_hash = UNHEX(SHA1(new.email)); -- You can remove UNHEX if you want human-readable value. You'll need binary(40) to hold it then 
END; 

DELIMITER ; 

從您的應用程序中，您只需提供名字，姓氏和電子郵件的值。 MySQL會處理重複項，它會告訴你狀態爲23000。我不知道如何使用asp.net，所以你必須以某種方式適應錯誤處理。

你可以在你的asp.net應用程序中處理哈希，但如果你感覺數據庫這樣做更舒服 - 我展示瞭如何通過觸發器實現它。

如果您需要手機號碼是唯一的或任何其他字段，則同樣的規則適用於手機號碼。當然，哈希數可能會產生比實際數更長的哈希值，在這種情況下，您可能直接將手機號碼設爲unique。

我希望這可以幫助你決定做什麼。

Answer 2

如果你正在做一個獨特的密鑰查找，它確實沒有足夠的性能差異來擔心索引是否被聚集。在向表中添加更多內容時，對其進行羣集可能是有意義的（或不是）。主要的是你有一個唯一的約束，很可能這將是主鍵，所以你會得到這個和相應的索引。性能會很好 - 關注其他用途。例如如果您想對域進行分析，則可能需要分解電子郵件地址。這可能更重要。最喜歡的事情，這取決於....

Answer 3

事情太多了評論...

如果你已經有INDEX(email)，然後簡單地把它變成UNIQUE(email)。表格（數據+索引）的大小不會改變（比ALTER多一點）。

如果email太大而無法索引 - 比如因爲它是TEXT - 那麼無法在email上添加UNIQUE索引。在這種情況下，「散列」解決方案將起作用。是的，它會爲磁盤使用增加兆字節，但這不太可能成爲問題。

如果您目前有id AUTO_INCREMENT和PRIMARY KEY(id)，那麼您是否真的在其他表中使用id？如果沒有，那麼我們可以討論其他路徑，例如使email或hashPRIMARY KEY。這可能甚至縮小磁盤的足跡。

不管你做什麼，都使用InnoDB。