索引的大小，會與效能掛上關係，但確不是絕對的關係..
最佳化的規劃，才會是重點...
來說個實際一點的..
台灣共有309個鄉鎮(數目若不對，敬請修正)，你去建立了一個參考資料表，共有兩個欄位，一個稱為代碼、另一個為鄉鎮名稱，這時你會發現，309，對資料庫來講，大才小用了，但是為了其關聯功能，所以你就不管三七二十一，給他建個【叢集】主索引，但是建完後，你會很快的發現索引比資料表還大.....這個東西在效能上，可能會有問題，因此你會再深入節思考，建立所謂的【叢集】主索引，是否有其必要，是否要建立非【叢集】主索引，這樣的效能是否會好一些，因為參考標旳資料並不多...
以上就是你在規劃時所需思考的問題，但不是全部都一樣的，要看你的工作目旳，所以，詳細的規劃才是你的重點，索引可能佔用的大小不是重點，效能考量才會是重點。

完全沒有這樣的說法。
這就好像是在問女人的體重要多重或多輕？
會是最吸引人的身材？

一個女人的身高170公分，50公斤？60公斤？還是40公斤？最吸引人？

40GB資料量，索引一定要20GB？
索引的大小和建了多少索引和用了多少欄位來當鍵值有關，還和Fill Factor有關，怎麼能直接量化成比例？
事實上，索引越小效率越好，這是基本道理。
但這個"越小"，能有多小，還是要看資料庫應用中規劃的索引有多少來決定。

並沒有什麼"黃金比例"的說法。

沒算過
主要取決你的Biz knowhow
將領域知識正規化或OO化
把Table 切的正確,PK,相關Key 設正確,型別搞懂

索引大小就不會錯太多