線上的資料庫發現索引不合理怎麼處理？

03-11

覺得公司資料庫的訂單表在索引設計方面存在一些不合理的地方，有些經常使用的關鍵欄位反倒沒有加索引，有些索引加了卻無用，因為只是渣渣實習生，不敢貿貿然跟經理提出，再次些做些功課，如果索引真存在問題，那麼在線上的數據增加一個索引或者更改一個索引會帶來什麼風險，已經有兩千萬數據的表，是否經得起這折騰？有勞大大們

在索引上踩過坑。。。。。

。

更改索引是一個風險很大的事情，尤其在不能完全摸清業務的所有查詢的情況下。所以一般不建議貿然刪除索引。

至於建立索引。這麼大的數據量直接添加索引會有一些問題，考慮題主在別的回答下的回復，題主公司的架構是傳統的主從關係架構。假設資料庫是MySQL，會有以下問題（想到哪寫到哪）

1.MySQL5.6之前的版本，添加索引，會阻塞讀寫，影響業務。

2.MySQL5.6添加索引具有新特性在線DDL，除了開始和結束階段，其他時間不阻塞讀寫。但是從庫複製是單線程的，所以會引起主從延遲。

3.如果使用在線DDL工具比如pt-osc，或者gh-ost,需要考慮到空間問題，以及業務上是否有觸發器、日誌是否是行模式之類的，好處是這類工具避免了1、2的問題。

4.好像還有什麼沒想到的。。。想到再補。。。

如果你有了利於公司的意見，一定要提出。至於領導怎麼看，那是他們的事情。

線上改動索引主要會帶來兩方面影響，一是創建索引一般都會長時間鎖表，導致阻塞其他請求。二是帶來大量IO，主要來自索引創建本身和生成該動作的日誌，有可能影響到其他請求的IO性能。有的DBMS針對這兩個影響會有針對性的選項比如聯機索引重建，用以縮短鎖表時間；粗粒度日誌記錄的恢復模式以減少日誌生成。採用這兩個選項的同時，我們還寫了個JOB每隔幾秒輪詢一下看是否有請求被索引創建的進程阻塞，如果有立刻KILL掉。因為是聯機索引重建，所以KILL掉後回滾時間也很短鎖也就很快釋放了。然而，在一個繁忙的系統中創建索引的請求幾乎總會被KILL掉。所以保險起見還是在宕機窗口中做吧。

已經存在比較多數據的表建索引，一般是另外搭建一套一模一樣的資料庫環境，建同樣結構的表，再把索引建上，然後，從原庫把數據導入新庫。最後修改應用層面的資料庫配置，切換到新庫。整個過程比較折騰。作為一個實習生提這個意見，本意很好，但是具體看團隊。在有的團隊會得到積極主動的正向激勵和反饋，有的團隊就覺得多事又愛表現。我覺得不妨向經理提出來，如果後果是後一種負面反饋，混點經驗值之後趁早逃離吧。

首先感謝邀請！

正確的創建和使用索引是實現高性能查詢的基礎，題主，你們的索引的確需要優化，才可以提高查詢速度。

如果單單深入的說索引優化，需要幾十頁才能說清楚，索引是一塊很深的話題，需要研究的東西很多，針對你上面的問題可以簡單談幾句。

你是mysql還是oracle還是其他資料庫，是不一樣的？

我只能從mysql資料庫出發，簡單的列幾個索引優化：

1、如果達到數據量2000萬，伺服器硬體性能一般的情況下，這個差不多也達到瓶頸了，你們可以考慮拆分表。

2、看了你描述，就是創建索引的欄位是否得當？索引要創建在where經常重複用到的欄位上，大的欄位盡量不要加（可前綴索引），這樣可以加快查詢速度。

3、你們需要刪除無用索引，單索引要創建在確實需要的地方，索引是佔用空間的、會影響update insert delete等速度。

注意、重點：

但是在2000萬下面建立索引需要大量時間，要考慮到對業務影響性能很大，特別如果有高並發業務的情況下，可能導致表鎖住、卡死、業務中斷等情況！！

每個技術人員都是因為自己有見解才能成功的，如果只是技術經理告訴你怎麼做就怎麼做，你憑什麼更進一步？

第一，如果目前的系統沒有因為索引而造成問題，那麼就不存在問題。故，命題不存在。

第二，如果可以確定索引在某個量級的數據下有問題，那麼可以模擬數據證明出來向上級提出，當然，前提是自己手頭的工作已經漂亮的完成，否則會引發政治問題。

資料庫查詢最慢的地方在於表和表關聯(先關聯出臨時結果集，再進行where)，那麼建立索引，主要就是解決表和表之間的關聯。經常使用的欄位，不一定是關聯欄位，索引應該建在關聯欄位的地方。要想知道你所想的對不對，就要去主動了解業務，知道表和表之間的關聯關係。

說出你的想法，告訴他們你的分析思路和解決方案，不論對錯，最起碼有你自己的思考…