周一夜間進行了一次xx業務相關的資料庫表優化。
原因：一共4張表，資料量不大，最小的40萬記錄，最大的300萬，大小不超過300mb。但由於歷史原因，表沒有建立索引，對應的服務使用的sql千姿百態，修改起來難度有點大，容易改錯，涉及的全國客戶較多，大部分都是全表掃瞄，在秒級的響應時間，但大多客戶還能忍著。
目標：對於此類無法通過建立索引提高響應速度的表，採用降低資料量，即水位線的方式，提高全表掃瞄的效率。
方案：經過多次改進，行程可用的方案：
第一部分：
1、create table ***_20130910 as select * from ***;
利用原表建立乙個中間表。
2、truncate ***;
truncate原表。
3、insert into *** select * from ***_20130910 where 7天;
將7天的資料插入原表。
此時啟動相應服務，這個過程可以保證利用最短的時間恢復生產表的使用。
第二部分：然後建立歷史表：
1、create table ***_history as select * from ***_20130910 where 1<>1;
利用中間表建立乙個空的歷史表。
2、建立夜維，用於每天將生產表7天之前的資料匯入歷史表。
整體操作完成後，用於生產的表保持7天的資料量，即使業務量增加，水位線也不會上公升太多，保持在一定的高度。同時通過將生產表歷史資料匯入歷史表的方式，既保證了歷史資料的備份，也保證了生產表的資料量。
上線：第一部分包括檢查的時間總共耗時20分鐘。與使用者確認測試後開始第二部分，大約用時10分鐘。
效果：當天上線後的效果還可以，大多應用的響應時間從秒級，下降到xx毫秒級，有待一段時間內的檢視。
總結：整體過程經過來多次修改與總結，且為上線當天整理了步驟手冊，標明了每步的操作以及注意的地方，所以操作當天比較順手，主要是與多個客戶聯絡停止應用、測試應用比較耗時，不同的客戶配合的程度不同，不過還算是比較配合。
對於資料庫表的優化，以上操作其實已經精簡到最簡單的語句了，我覺得優化操作不在於多麼的複雜，最重要的是簡單、有效、安全，何況是沒有使用者驅動的優化，做好了可能不會說你什麼，但做錯了就有人叫了，得不償失，因此不同的優化操作，可能選擇的方法不同，但核心應該堅持「簡單、有效、安全」，這樣才能做到畫龍點睛的效果。個人見解，歡迎拍磚！
資料庫優化 資料庫設計優化
一 索引優化 1.首先索引不是越多越好，要視情況而定。因為索引會降低insert和update的效率 insert和update有時可能會重建索引。2.乙個表的索參數量最好不要超過6個，擇優而建。3.專案上線後，根據使用者的查詢條件字段稍微調整資料庫中的字段索引。二 分表 1.縱切 根據表字段來且分...
資料庫引擎優化顧問優化資料庫
現在一直在做的專案，資料量相對也不小，開始的時候沒有覺得，因為是剛開始，資料量還很小，在程式使用過程中速度還挺快，但是隨著資料量的不停的增長，發現程式越來越慢，甚至出現了超時的問題，因此要對程式和資料庫進行優化，前期專案比較緊，沒有針對大資料量業務進行分析設計，所以索引等相關優化沒有做到位，通過後期...
資料庫優化
資料庫優化 1 合理使用索引 索引是資料庫中重要的資料結構，它的根本目的就是提高查詢效率。索引的使用要恰到好處，其使用原則如下 在經常進行連線，但是沒有指定為外來鍵的列上建立索引，而不經常連線的字段則由優化器自動生成索引 在頻繁進行排序或分組 即進行groupby或orderby操作 的列上建立索引...