有選擇地減少db索引的策略

我有一個索引字段users.username，它只在管理界面中使用。由於表格當前有很多寫入，我想刪除該索引。當然，我想保持索引可供管理員搜索。有選擇地減少db索引的策略

我可以提取整個列，將該索引移動到另一個表。但它感覺很蠢，因爲我已經計劃將寫重字段移到另一個表中（只有一個索引）。

在搜索引擎中投擲將是矯枉過正。

簡單解決方案的任何想法？

我剛剛意識到管理員搜索和排序大量字段的需求會影響許多表（實際上它們需要更多的索引）。對於第一步，我會確保管理員獲得一個專用的服務器+數據庫來阻止來自活動服務器的緩慢排序/搜索，並且從長遠來看，我將調查搜索引擎是否合適。謝謝大家！

來源

2010-12-22 eldergawd

「可搜索管理員」意味着「可以通過管理員搜索」或「能夠找到具有管理員身份的用戶名」？ – Quassnoi 2010-12-22 15:03:28

您是否檢查刪除此索引是否增加（顯着）您的寫入性能？ – Mchl 2010-12-22 15:06:27

MySQL不支持維護僅由某些用戶可訪問的索引，即使這樣，它也會像維護常用索引一樣昂貴。

假設用戶名是唯一的，你可以創建一個單獨的索引，如表這樣的：

CREATE TABLE shadow_username (username VARCHAR(100) NOT NULL PRIMARY KEY, userid INT NOT NULL, UNIQUE (userid))

，填寫及時：

TRUNCATE 
     shadow_username 

INSERT 
INTO shadow_username 
SELECT username, id 
FROM users

和查詢它：

SELECT u.* 
FROM (
     SELECT id 
     FROM shadow_username 
     WHERE username = 'user' 
     ) s 
JOIN users u 
ON  u.id = s.id 
UNION ALL 
SELECT u.* 
FROM users 
WHERE id > 
     (
     SELECT MAX(id) 
     FROM shadow_username 
     ) 
     AND username = 'user' 
UNION ALL 
SELECT * 
FROM users 
WHERE username = 'user' 
LIMIT 1

第一部分進行正常搜索;第二部分處理在shadow_username更新之間插入的用戶名;第三部分是一種後備方法，它只在前兩步找不到任何東西時才進行正常搜索（如果用戶更改了用戶名，則可能會發生這種情況）。

如果用戶名永不改變，則應該省略第三步。

來源

2010-12-22 15:31:24 Quassnoi

我不確定實際問題出在哪裏。要麼寫入「用戶名」字段，在這種情況下更新索引是有保證的（以及是否將索引進行索引是讀取性能和寫入性能之間的折衷），或者不寫入（我' d假設，因爲大多數用戶傾向於更改他們的名字而很少），在這種情況下，您的RDBMS根本不應該觸及索引。看着我的水晶球，我假設「用戶」表中的「寫入重量」字段是登錄會話，無論如何，它們應該存在於單獨的表中。

來源

2010-12-22 15:07:07

如果我正確理解你，你不能只有一個索引，只有一個子集的$ ways_to_access_data（即，管理界面vs公共接口）。

該列是索引，否則不是。

來源

2010-12-22 15:09:11 bhamby

有選擇地減少db索引的策略

回答

相關問題