MySQL：索引額外字段有什麼缺點？

我有這樣的talbe：MySQL：索引額外字段有什麼缺點？

CREATE TABLE UserTrans (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `user_id` int(10) unsigned NOT NULL, 
    `transaction_id` varchar(255) NOT NULL default '0', 
    `source` varchar(100) NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `user_id` (`user_id`) 
)

與InnoDB引擎。

transaction_id是var，因爲它有時可以是aphanumeric。

該id是主鍵。

so ..這是事情，我有超過1M的記錄。但是，有一個查詢在指定的源上檢查重複的transaciton_id。所以，這是我的查詢：

SELECT * 
    FROM UserTrans 
WHERE transaction_id = '212398043' 
    AND source = 'COMPANY_A';

這個查詢變得非常慢，就像現在運行2秒。我應該索引transaction_id和源？
例如KEY join_id（transaction_id，source）

如果我這樣做有什麼缺點？

來源

2010-09-16 murvinlai

很明顯，它的好處是它可以提高某些查詢的性能。

的缺點是，它會需要一點空間來存儲索引和一些工作的RDBMS來維持指數。索引特別容易消耗空間，因爲你的transaction_id是一個很寬的字符串。

你可能會考慮是否TRANSACTION_ID真正需要多達255個字符長，或者如果你可以聲明其最大長度是東西短。

或者你可以使用一個前綴索引索引只有第一ñ字符：

CREATE INDEX join_id ON UserTrans (transaction_id(16), source(16));

@Daniel好點，你可能會得到同樣的好處，並節省更多通過索引只有一列。既然你在做SELECT *你已經排除了覆蓋指數的好處。

另外，如果你打算使transaction_id唯一，爲什麼不把它限制爲唯一的？

CREATE UNIQE INDEX uq_transaction_id ON UserTrans (transaction_id(16));

來源

2010-09-16 02:48:30

+1有關前綴索引的好主意... – 2010-09-16 02:50:35

@Bill ...我認爲OP也可以考慮在transaction_id上單獨使用索引（或前綴索引），以節省空間......特別是如果'transaction_id'幾乎是唯一的。你會怎麼看？ – 2010-09-16 02:56:20

交易ID並不是唯一的。它在源頭上是獨一無二的。 :)另外，我其實不會做SELECT *，intead，我只是返回記錄ID。 :) – murvinlai 2010-09-16 03:02:38

主要缺點是新索引會佔用磁盤空間。它也會使插入和更新速度稍慢（但在大多數情況下這通常可以忽略不計）。

另一方面，您的查詢可能會運行幾毫秒而不是2秒。

來源

2010-09-16 02:45:25

到加算指標的缺點是空間（自從存儲索引不佔用空間）和插入時間（因爲當你插入新記錄，必須將它們添加到索引）。

也就是說，你可能不需要索引這兩個字段 - 只要索引其中一個字段就足夠了。

來源

2010-09-16 02:46:07 Amber

我會考慮diching你的id列，並使用TRANSACTION_ID作爲主鍵我假設TRANSACTION_ID是獨一無二的。

這意味着您的模式會阻止您插入已存在的事務ID。

這減少了存儲的數據量，也減少了需要編制索引的列數。

如果源公司和transaction_id事實上是一個複合鍵..我會使兩列成爲主鍵。

你目前的模式允許你放入重複的文件，這是一個不必要的惡習。

來源

2010-09-16 05:01:03 Bingy

不幸的是，每個來源的交易ID是唯一的，但有些來源沒有交易ID ..所以這就是爲什麼。 – murvinlai 2010-09-16 19:24:20

MySQL：索引額外字段有什麼缺點？

回答

相關問題