千萬級大表如何優(yōu)化，這是一個很有技術(shù)含量的問題，通常我們的直覺思維都會跳轉(zhuǎn)到拆分或者數(shù)據(jù)分區(qū)，在此我想做一些補(bǔ)充和梳理，想和大家做一些這方面的經(jīng)驗(yàn)總結(jié)，也歡迎大家提出建議。

從一開始腦海里開始也是火光四現(xiàn)，到不斷的自我批評，后來也參考了一些團(tuán)隊的經(jīng)驗(yàn)，我整理了下面的大綱內(nèi)容。

既然要吃透這個問題，我們勢必要回到本源，我把這個問題分為三部分:

“千萬級”，“大表”，“優(yōu)化”，

也分別對應(yīng)我們在圖中標(biāo)識的

“數(shù)據(jù)量”，“對象”和“目標(biāo)”。

我來逐步展開說明一下，從而給出一系列的解決方案。

1.數(shù)據(jù)量：千萬級

千萬級其實(shí)只是一個感官的數(shù)字，就是我們印象中的數(shù)據(jù)量大。 這里我們需要把這個概念細(xì)化，因?yàn)殡S著業(yè)務(wù)和時間的變化，數(shù)據(jù)量也會有變化，我們應(yīng)該是帶著一種動態(tài)思維來審視這個指標(biāo)，從而對于不同的場景我們應(yīng)該有不同的處理策略。

1) 數(shù)據(jù)量為千萬級，可能達(dá)到億級或者更高

通常是一些數(shù)據(jù)流水，日志記錄的業(yè)務(wù)，里面的數(shù)據(jù)隨著時間的增長會逐步增多，超過千萬門檻是很容易的一件事情。

2) 數(shù)據(jù)量為千萬級，是一個相對穩(wěn)定的數(shù)據(jù)量

如果數(shù)據(jù)量相對穩(wěn)定，通常是在一些偏向于狀態(tài)的數(shù)據(jù)，比如有1000萬用戶，那么這些用戶的信息在表中都有相應(yīng)的一行數(shù)據(jù)記錄，隨著業(yè)務(wù)的增長，這個量級相對是比較穩(wěn)定的。

3) 數(shù)據(jù)量為千萬級，不應(yīng)該有這么多的數(shù)據(jù)

這種情況是我們被動發(fā)現(xiàn)的居多，通常發(fā)現(xiàn)的時候已經(jīng)晚了，比如你看到一個配置表，數(shù)據(jù)量上千萬;或者說一些表里的數(shù)據(jù)已經(jīng)存儲了很久，99%的數(shù)據(jù)都屬于過期數(shù)據(jù)或者垃圾數(shù)據(jù)。

數(shù)據(jù)量是一個整體的認(rèn)識，我們需要對數(shù)據(jù)做更近一層的理解，這就可以引出第二個部分的內(nèi)容。

2.對象：數(shù)據(jù)表

數(shù)據(jù)操作的過程就好比數(shù)據(jù)庫中存在著多條管道，這些管道中都流淌著要處理的數(shù)據(jù)，這些數(shù)據(jù)的用處和歸屬是不一樣的。

一般根據(jù)業(yè)務(wù)類型把數(shù)據(jù)分為三種：

（1）流水型數(shù)據(jù)

流水型數(shù)據(jù)是無狀態(tài)的，多筆業(yè)務(wù)之間沒有關(guān)聯(lián)，每次業(yè)務(wù)過來的時候都會產(chǎn)生新的單據(jù)，比如交易流水、支付流水，只要能插入新單據(jù)就能完成業(yè)務(wù)，特點(diǎn)是后面的數(shù)據(jù)不依賴前面的數(shù)據(jù)，所有的數(shù)據(jù)按時間流水進(jìn)入數(shù)據(jù)庫。

（2）狀態(tài)型數(shù)據(jù)

狀態(tài)型數(shù)據(jù)是有狀態(tài)的，多筆業(yè)務(wù)之間依賴于有狀態(tài)的數(shù)據(jù)，而且要保證該數(shù)據(jù)的準(zhǔn)確性，比如充值時必須要拿到原來的余額，才能支付成功。

（3）配置型數(shù)據(jù)

此類型數(shù)據(jù)數(shù)據(jù)量較小，而且結(jié)構(gòu)簡單，一般為靜態(tài)數(shù)據(jù)，變化頻率很低。

至此，我們可以對整體的背景有一個認(rèn)識了，如果要做優(yōu)化，其實(shí)要面對的是這樣的3*3的矩陣，如果要考慮表的讀寫比例（讀多寫少，讀少寫多...），那么就會是3*3*4=24種，顯然做窮舉是不顯示的，而且也完全沒有必要，可以針對不同的數(shù)據(jù)存儲特性和業(yè)務(wù)特點(diǎn)來指定不同的業(yè)務(wù)策略。

對此我們采取抓住重點(diǎn)的方式，把常見的一些優(yōu)化思路梳理出來，尤其是里面的核心思想，也是我們整個優(yōu)化設(shè)計的一把尺子，而難度決定了我們做這件事情的動力和風(fēng)險。

而對于優(yōu)化方案，我想采用面向業(yè)務(wù)的維度來進(jìn)行闡述。

3.目標(biāo)：優(yōu)化

在這個階段，我們要說優(yōu)化的方案了，總結(jié)的有點(diǎn)多，相對來說是比較全了。

整體分為五個部分：

其實(shí)我們通常所說的分庫分表等方案只是其中的一小部分，如果展開之后就比較豐富了。

其實(shí)不難理解，我們要支撐的表數(shù)據(jù)量是千萬級別，相對來說是比較大了，DBA要維護(hù)的表肯定不止一張，如何能夠更好的管理，同時在業(yè)務(wù)發(fā)展中能夠支撐擴(kuò)展，同時保證性能，這是擺在我們面前的幾座大山。

我們分別來說一下這五類改進(jìn)方案：

優(yōu)化設(shè)計方案1.規(guī)范設(shè)計

在此我們先提到的是規(guī)范設(shè)計，而不是其他高大上的設(shè)計方案。

黑格爾說：秩序是自由的第一條件。在分工協(xié)作的工作場景中尤其重要，否則團(tuán)隊之間互相牽制太多，問題多多。

規(guī)范設(shè)計我想提到如下的幾個規(guī)范，其實(shí)只是屬于開發(fā)規(guī)范的一部分內(nèi)容，可以作為參考。

規(guī)范的本質(zhì)不是解決問題，而是有效杜絕一些潛在問題，對于千萬級大表要遵守的規(guī)范，我梳理了如下的一些細(xì)則，基本可以涵蓋我們常見的一些設(shè)計和使用問題，比如表的字段設(shè)計不管三七二十一，都是varchar(500),其實(shí)是很不規(guī)范的一種實(shí)現(xiàn)方式，我們來展開說一下這幾個規(guī)范。

1）配置規(guī)范

（1）MySQL數(shù)據(jù)庫默認(rèn)使用InnoDB存儲引擎。

（2）保證字符集設(shè)置統(tǒng)一，MySQL數(shù)據(jù)庫相關(guān)系統(tǒng)、數(shù)據(jù)庫、表的字符集使都用UTF8，應(yīng)用程序連接、展示等可以設(shè)置字符集的地方也都統(tǒng)一設(shè)置為UTF8字符集。

注：UTF8格式是存儲不了表情類數(shù)據(jù)，需要使用UTF8MB4，可在MySQL字符集里面設(shè)置。在8.0中已經(jīng)默認(rèn)為UTF8MB4，可以根據(jù)公司的業(yè)務(wù)情況進(jìn)行統(tǒng)一或者定制化設(shè)置。

（3）MySQL數(shù)據(jù)庫的事務(wù)隔離級別默認(rèn)為RR（Repeatable-Read），建議初始化時統(tǒng)一設(shè)置為RC（Read-Committed），對于OLTP業(yè)務(wù)更適合。

（4）數(shù)據(jù)庫中的表要合理規(guī)劃，控制單表數(shù)據(jù)量，對于MySQL數(shù)據(jù)庫來說，建議單表記錄數(shù)控制在2000W以內(nèi)。

（5）MySQL實(shí)例下，數(shù)據(jù)庫、表數(shù)量盡可能少；數(shù)據(jù)庫一般不超過50個，每個數(shù)據(jù)庫下，數(shù)據(jù)表數(shù)量一般不超過500個（包括分區(qū)表）。

2）建表規(guī)范

（1）InnoDB禁止使用外鍵約束，可以通過程序?qū)用姹ＷC。

（2）存儲精確浮點(diǎn)數(shù)必須使用DECIMAL替代FLOAT和DOUBLE。

（3）整型定義中無需定義顯示寬度，比如：使用INT，而不是INT(4)。

（4）不建議使用ENUM類型，可使用TINYINT來代替。

（5）盡可能不使用TEXT、BLOB類型，如果必須使用，建議將過大字段或是不常用的描述型較大字段拆分到其他表中；另外，禁止用數(shù)據(jù)庫存儲圖片或文件。

（6）存儲年時使用YEAR(4)，不使用YEAR(2)。

（7）建議字段定義為NOT NULL。

（8）建議DBA提供SQL審核工具，建表規(guī)范性需要通過審核工具審核后

3）命名規(guī)范

（1）庫、表、字段全部采用小寫。

（2）庫名、表名、字段名、索引名稱均使用小寫字母，并以“_”分割。

（3）庫名、表名、字段名建議不超過12個字符。（庫名、表名、字段名支持最多64個字符，但為了統(tǒng)一規(guī)范、易于辨識以及減少傳輸量，統(tǒng)一不超過12字符）

（4）庫名、表名、字段名見名知意，不需要添加注釋。

對于對象命名規(guī)范的一個簡要總結(jié)如下表4-1所示，供參考。

4）索引規(guī)范

（1）索引建議命名規(guī)則：idx_col1_col2[_colN]、uniq_col1_col2[_colN]（如果字段過長建議采用縮寫）。

（2）索引中的字段數(shù)建議不超過5個。

（3）單張表的索引個數(shù)控制在5個以內(nèi)。

（4）InnoDB表一般都建議有主鍵列，尤其在高可用集群方案中是作為必須項的。

（5）建立復(fù)合索引時，優(yōu)先將選擇性高的字段放在前面。

（6）UPDATE、DELETE語句需要根據(jù)WHERE條件添加索引。

（7）不建議使用%前綴模糊查詢，例如LIKE “%weibo”，無法用到索引，會導(dǎo)致全表掃描。

（8）合理利用覆蓋索引，例如：

（9）SELECT email,uid FROM user_email WHERE uid=xx，如果uid不是主鍵，可以創(chuàng)建覆蓋索引idx_uid_email(uid,email)來提高查詢效率。

（10）避免在索引字段上使用函數(shù)，否則會導(dǎo)致查詢時索引失效。

（11）確認(rèn)索引是否需要變更時要聯(lián)系DBA。

5）應(yīng)用規(guī)范

（1）避免使用存儲過程、觸發(fā)器、自定義函數(shù)等，容易將業(yè)務(wù)邏輯和DB耦合在一起，后期做分布式方案時會成為瓶頸。

（2）考慮使用UNION ALL，減少使用UNION，因?yàn)閁NION ALL不去重，而少了排序操作，速度相對比UNION要快，如果沒有去重的需求，優(yōu)先使用UNION ALL。

（3）考慮使用limit N，少用limit M，N，特別是大表或M比較大的時候。

（4）減少或避免排序，如：group by語句中如果不需要排序，可以增加order by null。

（5）統(tǒng)計表中記錄數(shù)時使用COUNT(*)，而不是COUNT(primary_key)和COUNT(1)；InnoDB表避免使用COUNT(*)操作，計數(shù)統(tǒng)計實(shí)時要求較強(qiáng)可以使用Memcache或者Redis，非實(shí)時統(tǒng)計可以使用單獨(dú)統(tǒng)計表，定時更新。

（6）做字段變更操作（modify column/change column）的時候必須加上原有的注釋屬性，否則修改后，注釋會丟失。

（7）使用prepared statement可以提高性能并且避免SQL注入。

（8）SQL語句中IN包含的值不應(yīng)過多。

（9）UPDATE、DELETE語句一定要有明確的WHERE條件。

（10）WHERE條件中的字段值需要符合該字段的數(shù)據(jù)類型，避免MySQL進(jìn)行隱式類型轉(zhuǎn)化。

（11）SELECT、INSERT語句必須顯式的指明字段名稱，禁止使用SELECT * 或是INSERT INTO table_name values()。

（12）INSERT語句使用batch提交（INSERT INTO table_name VALUES(),(),()……），values的個數(shù)不應(yīng)過多。

優(yōu)化設(shè)計方案2：業(yè)務(wù)層優(yōu)化

業(yè)務(wù)層優(yōu)化應(yīng)該是收益最高的優(yōu)化方式了，而且對于業(yè)務(wù)層完全可見，主要有業(yè)務(wù)拆分，數(shù)據(jù)拆分和兩類常見的優(yōu)化場景（讀多寫少，讀少寫多）

1）業(yè)務(wù)拆分

ü 將混合業(yè)務(wù)拆分為獨(dú)立業(yè)務(wù)

ü 將狀態(tài)和歷史數(shù)據(jù)分離

業(yè)務(wù)拆分其實(shí)是把一個混合的業(yè)務(wù)剝離成為更加清晰的獨(dú)立業(yè)務(wù)，這樣業(yè)務(wù)1，業(yè)務(wù)2。。。獨(dú)立的業(yè)務(wù)使得業(yè)務(wù)總量依舊很大，但是每個部分都是相對獨(dú)立的，可靠性依然有保證。

對于狀態(tài)和歷史數(shù)據(jù)分離，我可以舉一個例子來說明。

例如：我們有一張表Account，假設(shè)用戶余額為100。

我們需要在發(fā)生數(shù)據(jù)變更后，能夠追溯數(shù)據(jù)變更的歷史信息，如果對賬戶更新狀態(tài)數(shù)據(jù)，增加100的余額，這樣余額為200。

這個過程可能對應(yīng)一條update語句，一條insert語句。

對此我們可以改造為兩個不同的數(shù)據(jù)源，account和account_hist

在account_hist中就會是兩條insert記錄，如下:

而在account中則是一條update語句，如下：

這也是一種很基礎(chǔ)的冷熱分離，可以大大減少維護(hù)的復(fù)雜度，提高業(yè)務(wù)響應(yīng)效率。

2）數(shù)據(jù)拆分

2.1 按照日期拆分，這種使用方式比較普遍，尤其是按照日期維度的拆分，其實(shí)在程序?qū)用娴母膭雍苄?#xff0c;但是擴(kuò)展性方面的收益很大。

• 數(shù)據(jù)按照日期維度拆分，如test_20191021
• 數(shù)據(jù)按照周月為維度拆分,如test_201910
• 數(shù)據(jù)按照季度，年維度拆分,如test_2019

2.2 采用分區(qū)模式，分區(qū)模式也是常見的使用方式，采用hash,range等方式會多一些，在MySQL中我是不大建議使用分區(qū)表的使用方式，因?yàn)殡S著存儲容量的增長，數(shù)據(jù)雖然做了垂直拆分，但是歸根結(jié)底，數(shù)據(jù)其實(shí)難以實(shí)現(xiàn)水平擴(kuò)展，在MySQL中是有更好的擴(kuò)展方式。

2.3 讀多寫少優(yōu)化場景

采用緩存，采用Redis技術(shù)，將讀請求打在緩存層面，這樣可以大大降低MySQL層面的熱點(diǎn)數(shù)據(jù)查詢壓力。

2.4 讀少寫多優(yōu)化場景，可以采用三步走：

1) 采用異步提交模式，異步對于應(yīng)用層來說最直觀的就是性能的提升，產(chǎn)生最少的同步等待。

2) 使用隊列技術(shù)，大量的寫請求可以通過隊列的方式來進(jìn)行擴(kuò)展，實(shí)現(xiàn)批量的數(shù)據(jù)寫入。

3) 降低寫入頻率，這個比較難理解，我舉個例子

對于業(yè)務(wù)數(shù)據(jù)，比如積分類，相比于金額來說業(yè)務(wù)優(yōu)先級略低的場景，如果數(shù)據(jù)的更新過于頻繁，可以適度調(diào)整數(shù)據(jù)更新的范圍（比如從原來的每分鐘調(diào)整為10分鐘）來減少更新的頻率。

例如：更新狀態(tài)數(shù)據(jù)，積分為200，如下圖所示

可以改造為，如下圖所示。

如果業(yè)務(wù)數(shù)據(jù)在短時間內(nèi)更新過于頻繁，比如1分鐘更新100次，積分從100到10000，則可以根據(jù)時間頻率批量提交。

例如：更新狀態(tài)數(shù)據(jù)，積分為100，如下圖所示。

無需生成100個事務(wù)（200條SQL語句）可以改造為2條SQL語句，如下圖所示。

對于業(yè)務(wù)指標(biāo)，比如更新頻率細(xì)節(jié)信息，可以根據(jù)具體業(yè)務(wù)場景來討論決定。

優(yōu)化設(shè)計方案3：架構(gòu)層優(yōu)化

架構(gòu)層優(yōu)化其實(shí)就是我們認(rèn)為的那種技術(shù)含量很高的工作，我們需要根據(jù)業(yè)務(wù)場景在架構(gòu)層面引入一些新的花樣來。

3.1.系統(tǒng)水平擴(kuò)展場景

3.1.1采用中間件技術(shù)，可以實(shí)現(xiàn)數(shù)據(jù)路由，水平擴(kuò)展，常見的中間件有MyCAT，ShardingSphere,ProxySQL等

3.1.2 采用讀寫分離技術(shù)，這是針對讀需求的擴(kuò)展，更側(cè)重于狀態(tài)表，在允許一定延遲的情況下，可以采用多副本的模式實(shí)現(xiàn)讀需求的水平擴(kuò)展，也可以采用中間件來實(shí)現(xiàn)，如MyCAT,ProxySQL,MaxScale,MySQL Router等

3.1.3 采用負(fù)載均衡技術(shù)，常見的有LVS技術(shù)或者基于域名服務(wù)的Consul技術(shù)等

3.2.兼顧OLTP+OLAP的業(yè)務(wù)場景，可以采用NewSQL，優(yōu)先兼容MySQL協(xié)議的HTAP技術(shù)棧，如TiDB

3.3.離線統(tǒng)計的業(yè)務(wù)場景，有幾類方案可供選擇。

3.3.1 采用NoSQL體系，主要有兩類，一類是適合兼容MySQL協(xié)議的數(shù)據(jù)倉庫體系，常見的有Infobright或者ColumnStore，另外一類是基于列式存儲，屬于異構(gòu)方向，如HBase技術(shù)

3.3.2 采用數(shù)倉體系，基于MPP架構(gòu),如使用Greenplum統(tǒng)計，如T+1統(tǒng)計

優(yōu)化設(shè)計方案4：數(shù)據(jù)庫優(yōu)化

數(shù)據(jù)庫優(yōu)化，其實(shí)可打的牌也不少，但是相對來說空間沒有那么大了，我們來逐個說一下。

4.1 事務(wù)優(yōu)化

根據(jù)業(yè)務(wù)場景選擇事務(wù)模型，是否是強(qiáng)事務(wù)依賴

對于事務(wù)降維策略，我們來舉出幾個小例子來。

4.1.1 降維策略1：存儲過程調(diào)用轉(zhuǎn)換為透明的SQL調(diào)用

對于新業(yè)務(wù)而言，使用存儲過程顯然不是一個好主意，MySQL的存儲過程和其他商業(yè)數(shù)據(jù)庫相比，功能和性能都有待驗(yàn)證，而且在目前輕量化的業(yè)務(wù)處理中，存儲過程的處理方式太“重”了。

有些應(yīng)用架構(gòu)看起來是按照分布式部署的，但在數(shù)據(jù)庫層的調(diào)用方式是基于存儲過程，因?yàn)榇鎯^程封裝了大量的邏輯，難以調(diào)試，而且移植性不高，這樣業(yè)務(wù)邏輯和性能壓力都在數(shù)據(jù)庫層面了，使得數(shù)據(jù)庫層很容易成為瓶頸，而且難以實(shí)現(xiàn)真正的分布式。

所以有一個明確的改進(jìn)方向就是對于存儲過程的改造，把它改造為SQL調(diào)用的方式，可以極大地提高業(yè)務(wù)的處理效率，在數(shù)據(jù)庫的接口調(diào)用上足夠簡單而且清晰可控。

4.1.2 降維策略2：DDL操作轉(zhuǎn)換為DML操作

有些業(yè)務(wù)經(jīng)常會有一種緊急需求，總是需要給一個表添加字段，搞得DBA和業(yè)務(wù)同學(xué)都挺累，可以想象一個表有上百個字段，而且基本都是name1，name2……name100，這種設(shè)計本身就是有問題的，更不用考慮性能了。究其原因，是因?yàn)闃I(yè)務(wù)的需求動態(tài)變化，比如一個游戲裝備有20個屬性，可能過了一個月之后就增加到了40個屬性，這樣一來，所有的裝備都有40個屬性，不管用沒用到，而且這種方式也存在諸多的冗余。

我們在設(shè)計規(guī)范里面也提到了一些設(shè)計的基本要素，在這些基礎(chǔ)上需要補(bǔ)充的是，保持有限的字段，如果要實(shí)現(xiàn)這些功能的擴(kuò)展，其實(shí)完全可以通過配置化的方式來實(shí)現(xiàn)，比如把一些動態(tài)添加的字段轉(zhuǎn)換為一些配置信息。配置信息可以通過DML的方式進(jìn)行修改和補(bǔ)充，對于數(shù)據(jù)入口也可以更加動態(tài)、易擴(kuò)展。

4.1.3 降維策略3：Delete操作轉(zhuǎn)換為高效操作

有些業(yè)務(wù)需要定期來清理一些周期性數(shù)據(jù)，比如表里的數(shù)據(jù)只保留一個月，那么超出時間范圍的數(shù)據(jù)就要清理掉了，而如果表的量級比較大的情況下，這種Delete操作的代價實(shí)在太高，我們可以有兩類解決方案來把Delete操作轉(zhuǎn)換為更為高效的方式。

第一種是根據(jù)業(yè)務(wù)建立周期表，比如按照月表、周表、日表等維度來設(shè)計，這樣數(shù)據(jù)的清理就是一個相對可控而且高效的方式了。

第二種方案是使用MySQL rename的操作方式，比如一張2千萬的大表要清理99%的數(shù)據(jù)，那么需要保留的1%的數(shù)據(jù)我們可以很快根據(jù)條件過濾補(bǔ)錄，實(shí)現(xiàn)“移形換位”。

4.2 SQL優(yōu)化

其實(shí)相對來說需要的極簡的設(shè)計，很多點(diǎn)都在規(guī)范設(shè)計里面了，如果遵守規(guī)范，八九不離十的問題都會杜絕掉，在此補(bǔ)充幾點(diǎn)：

4.2.1 SQL語句簡化，簡化是SQL優(yōu)化的一大利器，因?yàn)楹唵?#xff0c;所以優(yōu)越。

4.2.2 盡可能避免或者杜絕多表復(fù)雜關(guān)聯(lián)，大表關(guān)聯(lián)是大表處理的噩夢，一旦打開了這個口子，越來越多的需求需要關(guān)聯(lián)，性能優(yōu)化就沒有回頭路了，更何況大表關(guān)聯(lián)是MySQL的弱項，盡管Hash Join才推出，不要像掌握了絕對大殺器一樣，在商業(yè)數(shù)據(jù)庫中早就存在，問題照樣層出不窮。

4.2.3 SQL中盡可能避免反連接，避免半連接，這是優(yōu)化器做得薄弱的一方面，什么是反連接，半連接？其實(shí)比較好理解，舉個例子，not in ,not exists就是反連接，in,exists就是半連接，在千萬級大表中出現(xiàn)這種問題，性能是幾個數(shù)量級的差異。

4.3 索引優(yōu)化

應(yīng)該是大表優(yōu)化中需要把握的一個度。

4.3.1 首先必須有主鍵，規(guī)范設(shè)計中第一條就是，此處不接收反駁。

4.3.2 其次，SQL查詢基于索引或者唯一性索引，使得查詢模型盡可能簡單。

4.3.3 最后，盡可能杜絕范圍數(shù)據(jù)的查詢，范圍掃描在千萬級大表情況下還是盡可能減少。

?

優(yōu)化設(shè)計方案4：管理優(yōu)化

這部分應(yīng)該是在所有的解決方案中最容易被忽視的部分了，我放在最后，在此也向運(yùn)維同事致敬，總是為很多認(rèn)為本應(yīng)該正常的問題盡職盡責(zé)（背鍋）。

千萬級大表的數(shù)據(jù)清理一般來說是比較耗時的，在此建議在設(shè)計中需要完善冷熱數(shù)據(jù)分離的策略，可能聽起來比較拗口，我來舉一個例子，把大表的Drop 操作轉(zhuǎn)換為可逆的DDL操作。

Drop操作是默認(rèn)提交的，而且是不可逆的，在數(shù)據(jù)庫操作中都是跑路的代名詞，MySQL層面目前沒有相應(yīng)的Drop操作恢復(fù)功能，除非通過備份來恢復(fù)，但是我們可以考慮將Drop操作轉(zhuǎn)換為一種可逆的DDL操作。

MySQL中默認(rèn)每個表有一個對應(yīng)的ibd文件，其實(shí)可以把Drop操作轉(zhuǎn)換為一個rename操作，即把文件從testdb遷移到testdb_arch下面；從權(quán)限上來說，testdb_arch是業(yè)務(wù)不可見的，rename操作可以平滑的實(shí)現(xiàn)這個刪除功能，如果在一定時間后確認(rèn)可以清理，則數(shù)據(jù)清理對于已有的業(yè)務(wù)流程是不可見的，如下圖所示。

此外，還有兩個額外建議，一個是對于大表變更，盡可能考慮低峰時段的在線變更，比如使用pt-osc工具或者是維護(hù)時段的變更，就不再贅述了。

最后總結(jié)一下，其實(shí)就是一句話：

千萬級大表的優(yōu)化是根據(jù)業(yè)務(wù)場景，以成本為代價進(jìn)行優(yōu)化的，絕對不是孤立的一個層面的優(yōu)化。

個人新書 《MySQL DBA工作筆記》

個人公眾號：jianrong-notes

總結(jié)

以上是生活随笔為你收集整理的排序千万级数据_MySQL 对于千万级的大表要怎么优化？我写了6000字的深度解读...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。