資料庫優化小計

週一夜間進行了一次XX業務相關的資料庫表優化。

原因：

一共4張表，資料量不大，最小的40萬記錄，最大的300萬，大小不超過300MB。但由於歷史原因，表沒有建立索引，對應的服務使用的SQL千姿百態，修改起來難度有點大，容易改錯，涉及的全國客戶較多，大部分都是全表掃描，在秒級的響應時間，但大多客戶還能忍著。

目標：

對於此類無法通過建立索引提高響應速度的表，採用降低資料量，即水位線的方式，提高全表掃描的效率。

方案：

經過多次改進，行程可用的方案：

第一部分：

1、CREATE TABLE XXX_20130910 AS SELECT * FROM XXX;

利用原表建立一箇中間表。

2、TRUNCATE XXX;

Truncate原表。

3、INSERT INTO XXX SELECT * FROM XXX_20130910 WHERE 7天;

將7天的資料插入原表。

此時啟動相應服務，這個過程可以保證利用最短的時間恢復生產表的使用。

第二部分：然後建立歷史表：

1、CREATE TABLE XXX_HISTORY AS SELECT * FROM XXX_20130910 WHERE 1<>1;

利用中間表建立一個空的歷史表。

2、建立夜維，用於每天將生產表7天之前的資料匯入歷史表。

整體操作完成後，用於生產的表保持7天的資料量，即使業務量增加，水位線也不會上升太多，保持在一定的高度。同時通過將生產表歷史資料匯入歷史表的方式，既保證了歷史資料的備份，也保證了生產表的資料量。

上線：

第一部分包括檢查的時間總共耗時20分鐘。與使用者確認測試後開始第二部分，大約用時10分鐘。

效果：

當天上線後的效果還可以，大多應用的響應時間從秒級，下降到xx毫秒級，有待一段時間內的檢視。

總結：

整體過程經過來多次修改與總結，且為上線當天整理了步驟手冊，標明瞭每步的操作以及注意的地方，所以操作當天比較順手，主要是與多個客戶聯絡停止應用、測試應用比較耗時，不同的客戶配合的程度不同，不過還算是比較配合。

對於資料庫表的優化，以上操作其實已經精簡到最簡單的語句了，我覺得優化操作不在於多麼的複雜，最重要的是簡單、有效、安全，何況是沒有使用者驅動的優化，做好了可能不會說你什麼，但做錯了就有人叫了，得不償失，因此不同的優化操作，可能選擇的方法不同，但核心應該堅持“簡單、有效、安全”，這樣才能做到畫龍點睛的效果。個人見解，歡迎拍磚！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-772658/，如需轉載，請註明出處，否則將追究法律責任。