數據庫發展到今天已經有半個世紀，這期間一代又一代產品涌現而出，越來越多的新特性如同雨后春筍。積累到今天，一個成熟的數據庫產品，亮點特性可能用百計算也不為過。有些特性看上去樸實無華，往往成為了DBA最喜歡的，有的看上去十分有用，但是實際生產過程中，我卻不敢用。盤點一下那些看上去很好，我卻不敢用的特性。

特性一：自動主備切換

很多數據庫都以這個作為宣傳點，但是在我十年DBA生涯中，生產環境做主備切換的場景，有一次算一次，全部都是手動切換。

一方面是，公司對于數據庫主備切換，有著嚴格的規章制度。尤其在金融行業，做一次切換都要主動上報監管，再寫一份報告。如果誰在報告里把切換原因寫成了自動切換，估計內部都不會通過，當天就會被合規部門請去喝茶談天。一次主備切換，必須是由運維負責人和對應系統的負責人同時拍板才生效，DBA是沒有權限自己做決定的。

另一方面，數據庫支持自動主備切換，但是應用程序不一定支持。一個公司應用程序少則幾十個，多則幾百個，開發的公司水平不一，運維的熟悉程度有淺有深。光是數據庫支持自動切換，應用程序不支持，那等于沒有。即便是自動切換過去，誰也不敢保證平時一直不用的在被環境能夠支撐起業務的必要需求和基本并發量。

自動主備切換，作為一個宣傳點來宣傳高可用的能力是可以的，但是如果作為一個公司生產環境尤其是重要的核心系統的時候，真正決定需要做主備切換的時候，往往是需要流程和決策的，自動顯然不行。

特性二：存儲自動擴展

很多數據庫都帶有這個功能，自動擴展表數據文件。我相信這個功能的本意是好的，讓DBA不再過分關注文件使用量。但是實際生產中，我就職過的兩家公司都有過規章制度，除非特殊需求或P0級別的系統例如財務，禁止開通自動擴展功能。多數時間里，只能監控文件或者表空間的使用量，到達一個閾值之后觸發告警來決定是否擴展。

其實這和很多數據庫服務器的使用情況是分不開的。一些甲方公司it預算有限，往往把一些非核心的系統按照表空間或者不同數據文件分隔，放到一個數據庫實例中。最多的時候，我運維過一個數據庫實例，上面跑了超過20個業務系統。這些非核心的業務系統寫的怎么樣就比較隨緣了，有的業務邏輯有問題的，開了自增分分鐘給你把存儲空間干滿。這時候如果恰好又有其他系統要自增的時候，對不起沒空間了。這時候就得找存儲管理員去要空間。新空間怎么找業務部門算費用，又是一個讓人頭疼的事。其實很多時候，都不是技術問題，還是錢和話語權的問題。

如果不自增，恰好某個業務系統出現數據量暴漲怎么辦？通常會在系統上線之前告知是否能接受這種情況，如果業務方不能接受，那么請自己提預算買專用服務器，否則我們提供的標準服務就是這樣。一開始把事情都定好，后續的很多問題都能把麻煩盡量減少。

特性三：閃回特性

閃回這個功能在實際生產中，我是不敢輕易用的，一方面會生成出更多的日志量增加存儲開銷，另一方面是閃回有可能造成一些無法預料的后果。

全庫閃回往往拿來做一些非生產時段的用途，比如做系統升級或者災備演練，這個時候全庫閃回就是一個利器。但是生產時段全庫閃回，誰都不敢保證，閃回到的時間點到底是不是那個時間點，兩個時間點之間有哪些業務數據是實際需要但是又閃回沒了的，也沒有人會說的清楚。

單表閃回相對風險低一點，一個是范圍有限，另一個是哪怕出了問題，補救的工作量也是可以評估的。然而不到萬不得已，例如緊急且重要的業務需求，并且業務部門書面承諾自行承擔所有風險，我是不敢使用。寧可找一臺恢復機用備份+日志的方式，還原到某個指定的點。因為即便是單表，復雜的業務系統下，很可能有其他表需要讀取關聯數據，其影響面往往比我們想象的還要大。