存儲(chǔ)優(yōu)化下數(shù)據(jù)庫(kù)s的使用和論壇

1、最新更新通知 加ixuexi66資料整理不易個(gè)人學(xué)習(xí)倒賣(mài) Android開(kāi)發(fā)高手課首頁(yè)|優(yōu)化（下）：數(shù)據(jù)庫(kù)的使用和優(yōu)化14 |2019-01-15講述：時(shí)長(zhǎng) 15:49大小 14.50M我們先來(lái)復(fù)習(xí)一下前面講到的方法的使用場(chǎng)景：少量的 Key Value 數(shù)據(jù)可以直接使用SharedPreferences，稍微復(fù)雜一些的數(shù)據(jù)類(lèi)型也可以通過(guò)序列化成 JSON 或者 ProtocolBuffers 保存，并且在開(kāi)發(fā)中獲取或者修改數(shù)據(jù)也很簡(jiǎn)單。不過(guò)這幾種方法可以覆蓋所有的還可以接受，但如果是幾萬(wàn)條的數(shù)據(jù)做增刪改查呢？場(chǎng)景嗎？數(shù)據(jù)量在幾百上千條這個(gè)量級(jí)時(shí)它們的性能呢？而且如何實(shí)現(xiàn)快速地對(duì)某幾個(gè)人的對(duì)于

2、大數(shù)據(jù)的場(chǎng)景，我們需要考慮穩(wěn)定性、性能和可擴(kuò)展性，這個(gè)時(shí)候就要輪到今天的“主角”數(shù)據(jù)庫(kù)登場(chǎng)了。講優(yōu)化一定繞不開(kāi)數(shù)據(jù)庫(kù)，而數(shù)據(jù)庫(kù)這個(gè)主題又非常大，我也知道不少同學(xué)學(xué)數(shù)據(jù)庫(kù)的過(guò)程是從入門(mén)到放棄。那么考慮到我們大多是從事移動(dòng)開(kāi)發(fā)的工作，今天我就來(lái)講講移動(dòng)端數(shù)據(jù)庫(kù)的使用和優(yōu)化。的那些事兒雖然市面上有很多的數(shù)據(jù)庫(kù)，但受限于庫(kù)體積和空間，適合移動(dòng)端使用的還真不多。當(dāng)然使用最廣泛的還是我們今天的主角，但同樣還是有一些其他不錯(cuò)的選擇，例如創(chuàng)業(yè)團(tuán)隊(duì)的Realm、的LevelDB等。在國(guó)內(nèi)那么多的移動(dòng)團(tuán)隊(duì)中，對(duì)的研究可以算是最深入的。這其實(shí)是業(yè)務(wù)訴求導(dǎo)向的，用戶只會(huì)在本地保存，一旦出現(xiàn)數(shù)據(jù)損壞或者丟失，對(duì)用戶來(lái)說(shuō)

3、都是不可挽回的。另一方面，有很大一批的重度用戶，他們有幾千個(gè)人、幾千個(gè)群聊天，曾經(jīng)做過(guò)一個(gè)統(tǒng)計(jì)，有幾百萬(wàn)用戶的數(shù)據(jù)庫(kù)竟然大于 1GB。對(duì)于這批用戶，如何保證他們可以正常地使用是一個(gè)非常大的。所以當(dāng)時(shí)專(zhuān)門(mén)開(kāi)展了一個(gè)重度用戶優(yōu)化的專(zhuān)項(xiàng)。一開(kāi)始的時(shí)候我們集中在使的實(shí)現(xiàn)也用上的優(yōu)化，例如表結(jié)構(gòu)、索引等。但很快就發(fā)現(xiàn)由于系統(tǒng)版本的不同，有所差異，經(jīng)常會(huì)出現(xiàn)一些兼容性問(wèn)題，并且也考慮到加密的訴求，我們決定單獨(dú)引入自己的版本。“源碼在手，天下我有”，從此開(kāi)啟了一條研究數(shù)據(jù)庫(kù)的“不歸路”。那時(shí)我們投入了幾個(gè)人專(zhuān)門(mén)去深入研究的源碼，從的 PRAGMA 編譯選項(xiàng)、Cursor 實(shí)現(xiàn)優(yōu)化，到源碼的優(yōu)化，最后打造出從

4、到線上的整個(gè)體系。在 2017 年，我們開(kāi)源了項(xiàng)目是否靠譜，就看這個(gè)項(xiàng)目對(duì)版本，雖然我現(xiàn)在已經(jīng)離開(kāi)了的數(shù)據(jù)庫(kù)WCDB。這里多說(shuō)兩句，看一個(gè)開(kāi)源本身有多重要。開(kāi)源堅(jiān)持內(nèi)部與外部使用同一個(gè)團(tuán)隊(duì)，但還是歡迎有需要的同學(xué)使用 WCDB。在開(kāi)始學(xué)習(xí)前我要提醒你，的優(yōu)化同樣也很難通過(guò)一兩篇文章就把每個(gè)細(xì)節(jié)都講清楚。今天的內(nèi)容我選擇了一些比較重要的知識(shí)點(diǎn)，并且為你準(zhǔn)備了大量的參考資料，遇到陌生或者不懂的地方需要結(jié)合參考資料反復(fù)學(xué)習(xí)。1. ORM坦白說(shuō)可能很多 BAT 的高級(jí)開(kāi)發(fā)工程師都全了解的內(nèi)部機(jī)制，也不能正確地寫(xiě)出高效的 SQL 語(yǔ)句。大部分應(yīng)用為了提高開(kāi)發(fā)效率，會(huì)引入 ORM 框架。ORM（Objec

5、t Relational Mapping）也就是對(duì)象關(guān)系，用面向?qū)ο蟮母拍畎褦?shù)據(jù)庫(kù)中表和對(duì)象關(guān)聯(lián)起來(lái)，可以讓我們不用關(guān)心數(shù)據(jù)庫(kù)底層的實(shí)現(xiàn)。最新更新通知 加ixuexi66資料整理不易個(gè)人學(xué)習(xí)倒賣(mài)Android 中最常用的 ORM 框架有開(kāi)源greenDAO和ORM 框架會(huì)帶來(lái)什么問(wèn)題呢？的Room，那使用使用 ORM 框架真的非常簡(jiǎn)單，但是簡(jiǎn)易性是需要犧牲部分執(zhí)行效率為代價(jià)的，具體的損耗跟 ORM 框架寫(xiě)得好不好很有關(guān)系。但可能更大的問(wèn)題是讓很多的開(kāi)發(fā)者的思維，最后可能連簡(jiǎn)單的 SQL 語(yǔ)句都寫(xiě)了。那我們的應(yīng)用是否應(yīng)該引入 ORM 框架呢？可能程序員天生追求偷懶，為了提高開(kāi)發(fā)效率，應(yīng)用的確應(yīng)該

6、引入 ORM 框架。但是這不能是我們可以不去學(xué)習(xí)數(shù)據(jù)庫(kù)基礎(chǔ)知識(shí)的理由，只有理解底層的一些機(jī)制，我們才能更加得心應(yīng)手地解決疑難的問(wèn)題?？紤]到可以更好的與 Android Jetpack 的組件互動(dòng)，WCDB 選擇 Room 作為 ORM 框架。2. 進(jìn)程與線程并發(fā)如果我們?cè)陧?xiàng)目中有使用經(jīng)常會(huì)出現(xiàn)的一個(gè)問(wèn)題。，那么下面這個(gè)DatabaseLockedException就是代碼1234android.database.DatabaseLockedException: database is locked Database.dbopenDatabase.openDatabaseDatabase.ope

7、nDatabaseatat atandroid.database.android.database. android.database.DatabaseLockedException 歸根到底是因?yàn)椴l(fā)導(dǎo)致，而的并發(fā)有兩個(gè)維度，一個(gè)是多進(jìn)程并發(fā)，一個(gè)是多線程并發(fā)。下面我們分別來(lái)講一下它們的關(guān)鍵點(diǎn)。多進(jìn)程并發(fā)默認(rèn)是支持多進(jìn)程并發(fā)操作的，它通過(guò)文件鎖來(lái)多進(jìn)程的并發(fā)。鎖的粒度并沒(méi)有非常細(xì)，它文章。的是整個(gè) DB 文件，內(nèi)部有 5 個(gè)狀態(tài)，具體你可以參考下面的文檔：locking源碼分析：鎖機(jī)制簡(jiǎn)介 機(jī)制簡(jiǎn)單來(lái)說(shuō)，多進(jìn)程可以同時(shí)獲取 SHARED 鎖來(lái)數(shù)據(jù)，但是只有一個(gè)進(jìn)程可以獲取EXCLUSIVE

8、鎖來(lái)寫(xiě)數(shù)據(jù)庫(kù)。對(duì)于 iOS 來(lái)說(shuō)可能沒(méi)有多進(jìn)程locking_mode 的默認(rèn)值改為 EXCLUSIVE。數(shù)據(jù)庫(kù)的場(chǎng)景，可以把代碼1 PRAGMA locking_mode = EXCLUSIVE在 EXCLUSIVE 模式下，數(shù)據(jù)庫(kù)連接在斷開(kāi)前都文件的鎖，從而避免不必要的，提高數(shù)據(jù)庫(kù)的速度。多線程并發(fā)相比多進(jìn)程，多線程的數(shù)據(jù)庫(kù)啟下面的配置，當(dāng)然系統(tǒng)可能會(huì)更加常見(jiàn)。支持多線程并發(fā)模式，需要開(kāi)會(huì)默認(rèn)開(kāi)啟多線程Multi-thread 模式。代碼1 PRAGMA_THREADSAFE =2跟多進(jìn)程的鎖機(jī)制一樣，為了實(shí)現(xiàn)簡(jiǎn)單，鎖的粒度都是數(shù)據(jù)庫(kù)文件級(jí)別，并沒(méi)有實(shí)現(xiàn)表級(jí)甚至行級(jí)的鎖。還有需要說(shuō)明的是，

9、同一個(gè)句柄同一時(shí)間只有一個(gè)線程在操作，這個(gè)時(shí)候我們需要打開(kāi)連接池 Connection Pool。如果使用 WCDB 在初始化的時(shí)候可以指定連接池的大小，在中我們?cè)O(shè)置的大小是 4。代碼12345publicstaticDatabase openDatabase (String path, Database.CursorFactory factory,int flags,DatabaseErrorHandler errorHandler, int poolSize)最新一手資源 更新通知 加微信 ixuexi66資料整理不易 僅供個(gè)人學(xué)習(xí) 請(qǐng)勿倒賣(mài)跟多進(jìn)程類(lèi)似，多線程可以同時(shí)讀取數(shù)據(jù)庫(kù)數(shù)據(jù)，但是

10、寫(xiě)數(shù)據(jù)庫(kù)依然是互斥的。SQLite 提供了 Busy Retry 的方案，即發(fā)生阻塞時(shí)會(huì)觸發(fā) Busy Handler，此時(shí)可以讓線程休眠一段時(shí)間后，重新嘗試操作，你可以參考微信 iOS SQLite 源碼優(yōu)化實(shí)踐這篇文章。為了進(jìn)一步提高并發(fā)性能，我們還可以打開(kāi)WAL（Write-Ahead Logging）模式。WAL 模式會(huì)將修改的數(shù)據(jù)單獨(dú)寫(xiě)到一個(gè) WAL 文件中，同時(shí)也會(huì)引入了 WAL 日志文件鎖。通過(guò) WAL 模式讀和寫(xiě)可以完全地并發(fā)執(zhí)行，不會(huì)互相阻塞。復(fù)制代碼1 PRAGMA schema.journal_mode = WAL但是需要注意的是，寫(xiě)之間是仍然不能并發(fā)。如果出現(xiàn)多個(gè)寫(xiě)并發(fā)

11、的情況，依然有可能會(huì)出現(xiàn) SQLiteDatabaseLockedException。這個(gè)時(shí)候我們可以讓?xiě)?yīng)用中捕獲這個(gè)異常，然后等待一段時(shí)間再重試。復(fù)制代碼1 catch (SQLiteDatabaseLockedException e) 2 if (sqliteLockedExceptionTimes < (tryTimes - 1) 3 try 4 Thread.sleep(100);5 catch (InterruptedException e1) 6 7 8 sqliteLockedExceptionTimes+；9 總的來(lái)說(shuō)通過(guò)連接池與 WAL 模式，我們可以很大程度上增加 S

12、QLite 的讀寫(xiě)并發(fā)，大大減少由于并發(fā)導(dǎo)致的等待耗時(shí)，建議大家在應(yīng)用中可以嘗試開(kāi)啟。3. 查詢優(yōu)化說(shuō)到數(shù)據(jù)庫(kù)的查詢優(yōu)化，你第一個(gè)想到的肯定是建索引，那我就先來(lái)講講 SQLite 的索引優(yōu)化。索引優(yōu)化正確使用索引在大部分的場(chǎng)景可以大大降低查詢速度，微信的數(shù)據(jù)庫(kù)優(yōu)化也是通過(guò)索引開(kāi)始。下面是索引使用非常簡(jiǎn)單的一個(gè)例子，我們先從索引表找到數(shù)據(jù)對(duì)應(yīng)的 rowid，然后再?gòu)脑瓟?shù)據(jù)表直接通過(guò) rowid 查詢結(jié)果。關(guān)于 SQLite 索引的原理網(wǎng)上有很多文章，在這里我推薦一些參考資料給你：SQLite 索引的原理官方文檔：Query PlanningMySQL 索引背后的數(shù)據(jù)結(jié)構(gòu)及算法原理這里的關(guān)鍵在于如

13、何正確的建立索引，很多時(shí)候我們以為已經(jīng)建立了索引，但事實(shí)上并沒(méi)有真正生效。例如使用了 BETWEEN、LIKE、OR 這些操作符、使用表達(dá)式或者 case when 等。更詳細(xì)的規(guī)則可參考官方文檔The SQLite Query Optimizer Overview，下面是一個(gè)通過(guò)優(yōu)化轉(zhuǎn)換達(dá)到使用索引目的的例子。復(fù)制代碼1 BETWEEN： myfiedl 索引無(wú)法生效2 SELECT * FROM mytable WHERE myfield BETWEEN 10 and 20;3 轉(zhuǎn)換成： myfiedl 索引可以生效4 SELECT * FROM mytable WHERE myfield

14、 >= 10 AND myfield <= 20;建立索引是有代價(jià)的，需要一直維護(hù)索引表的更新。比如對(duì)于一個(gè)很小的表來(lái)說(shuō)就沒(méi)必要建索引；如果一個(gè)表經(jīng)常是執(zhí)行插入更新操作，那么也需要節(jié)制的建立索引。總的來(lái)說(shuō)有幾個(gè)原則：建立正確的索引。這里不僅需要確保索引在查詢中真正生效，我們還希望可以選擇最高效的索引。如果一個(gè)表建立太多的索引，那么在查詢的時(shí)候 SQLite 可能不會(huì)選擇最好的來(lái)執(zhí)行。最新 更新通知 加 ixuexi66資料整理不易 個(gè)人學(xué)習(xí) 倒賣(mài)單列索引、多列索引與復(fù)合索引的選擇。索引要綜合數(shù)據(jù)表中不同的 與排序語(yǔ)句一起考慮，如果 結(jié)果集過(guò)大，還是希望可以通過(guò)復(fù)合索引直接在索引表返

15、回 結(jié) 果。索引字段的選擇。整型類(lèi)型索引效率會(huì)遠(yuǎn)高于字符串索引，而對(duì)于主鍵 會(huì)默認(rèn)幫我們建立索引，所以主鍵盡量不要用復(fù)雜字段?？偟膩?lái)說(shuō)索引優(yōu)化是 優(yōu)化中最簡(jiǎn)單同時(shí)也是最有效的，但是它并不是簡(jiǎn)單的建一個(gè)索引就可以了，有的時(shí)候我們需要進(jìn)一步調(diào)整 語(yǔ)句甚至是表的結(jié)構(gòu)，這樣才能達(dá)到最好的效果。頁(yè)大小與緩存大小在 I/O 文件系統(tǒng)中，我講過(guò)數(shù)據(jù)庫(kù)就像一個(gè)小文件系統(tǒng)一樣，事實(shí)上它內(nèi)部也有頁(yè)和緩存的概念。對(duì)于 的 DB 文件來(lái)說(shuō)，頁(yè)（page）是最小的 ，如下圖所示每個(gè)表對(duì)應(yīng)的數(shù)據(jù)在整個(gè) DB 文件中都是通過(guò)一個(gè)一個(gè)的頁(yè) ，屬于同一個(gè)表不同的頁(yè)以 B 樹(shù)（B- tree）的方式組織索引，每一個(gè)表都是一棵 B

16、 樹(shù)。跟文件系統(tǒng)的頁(yè)緩存（Page Cache）一樣， 會(huì)將讀過(guò)的頁(yè)緩存起來(lái)，用來(lái)加快下一次 速度。頁(yè)大小默認(rèn)是 1024Byte，緩存大小默認(rèn)是 1000 頁(yè)。 的編譯參數(shù)你可以查看官方文檔PRAGMA Statements。復(fù)制代碼1 PRAGMA page_size = 10242 PRAGMA cache_size = 1000每個(gè)頁(yè)永遠(yuǎn)只存放一個(gè)表或者一組索引的數(shù)據(jù)，即不可能同一個(gè)頁(yè)存放多個(gè)表或索引的數(shù) 據(jù)，表在整個(gè) DB 文件的第一個(gè)頁(yè)就是這棵 B 樹(shù)的根頁(yè)。繼續(xù)以上圖為例，如果想查詢r(jià)owID 為 N+2 的數(shù)據(jù)，我們首先要從 sqlite_master 查找出 table 的

17、root page 的位置，然后讀取 root page、page4 這兩個(gè)頁(yè)，所以一共會(huì)需要 3 次 I/O。從上表可以看到，增大 page size 并不能不斷地提升性能，在拐點(diǎn)以后可能還會(huì)有副作用。我們可以通過(guò) PRAGMA 改變默認(rèn) page size 的大小，也可以再創(chuàng)建 DB 文件的時(shí)候進(jìn)行設(shè)置。但是需要注意如果存在老的數(shù)據(jù)，需要調(diào)用 vacuum 對(duì)數(shù)據(jù)表對(duì)應(yīng)的節(jié)點(diǎn)重新計(jì)算分配大小。在微信的內(nèi)部測(cè)試中，如果使用 4KB 的 page size 性能提升可以在 5%10%。但是考慮到歷史數(shù)據(jù)的遷移成本，最終還是使用 1024Byte。所以這里建議大家在新建數(shù)據(jù)庫(kù)的時(shí) 最新 更新通知

18、 加 ixuexi66資料整理不易 個(gè)人學(xué)習(xí) 倒賣(mài)候，就提前選擇 4KB 作為默認(rèn)的 page size 以獲得更好的性能。其他優(yōu)化關(guān)于 的使用優(yōu)化還有很多很多，下面我簡(jiǎn)單提幾個(gè)點(diǎn)。慎用“select*”，需要使用多少列，就選取多少列。正確地使用事務(wù)。預(yù)編譯與參數(shù)綁定，緩存被編譯后的 SQL 語(yǔ)句。對(duì)于 blob 或超大的 Text 列，可能會(huì)超出一個(gè)頁(yè)的大小，導(dǎo)致出現(xiàn)超大頁(yè)。建議將這些列單獨(dú)拆表，或者放到表字段的后面。定期整理或者 無(wú)用或可刪除的數(shù)據(jù)，例如 數(shù)據(jù)庫(kù)會(huì)刪除比較久遠(yuǎn)的數(shù)據(jù)，如果用戶 到這部分?jǐn)?shù)據(jù)，重新從 拉取即可。在日常的開(kāi)發(fā)中，我們都應(yīng)該對(duì)這些知識(shí)有所了解，再來(lái)復(fù)習(xí)一下上面學(xué)到

19、的 優(yōu)化方法。通過(guò)引進(jìn) ORM，可以大大的提升我們的開(kāi)發(fā)效率。通過(guò) WAL 模式和連接池， 可以提高 的并發(fā)性能。通過(guò)正確的建立索引，可以提升 的 速度。通過(guò)調(diào)整默認(rèn)的頁(yè)大小和緩存大小，可以提升 的整體性能。的其他特性除了 的優(yōu)化經(jīng)驗(yàn)，我在 的工作中還積累了很多使用的經(jīng)驗(yàn)，下面我挑選了幾個(gè)比較重要的經(jīng)驗(yàn)把它 給你。1. 損壞與恢復(fù)中 的損耗率在 1/200001/10000 左右，雖然看起來(lái)很低，不過(guò)意考慮到微信的體量，這個(gè)問(wèn)題還是不容忽視的。特別是如果某些大佬的 丟失，我們團(tuán)隊(duì)都會(huì)承受超大的 。創(chuàng)新是為了解決焦慮，技術(shù)都是逼出來(lái)的。對(duì)于 損壞與恢復(fù)的研究，可以說(shuō)是微信投入比較大的一塊。關(guān)于

20、數(shù)據(jù)庫(kù)的損耗與修復(fù)，以及 在這里的優(yōu)化成果， 你可以參考下面這些資料。How To Corrupt An Database File 數(shù)據(jù)庫(kù)修復(fù)實(shí)踐 移動(dòng)端數(shù)據(jù)庫(kù)組件 WCDB 系列（二） 數(shù)據(jù)庫(kù)修復(fù)三板斧WCDB Android 數(shù)據(jù)庫(kù)修復(fù)2. 加密與安全數(shù)據(jù)庫(kù)的安全主要有兩個(gè)方面，一個(gè)是防注入，一個(gè)是加密。防注入可以通過(guò)靜態(tài)安全掃描的方式，而 般會(huì)使用 SQLCipher 支持。的加 都是以頁(yè)為 ，默認(rèn)會(huì)使用 AES 算法加密，加 / 的耗時(shí)跟選用的密鑰長(zhǎng)度有關(guān)。下面是WCDB Android Benchmark的數(shù)據(jù)，詳細(xì)的信息請(qǐng)查看 里的說(shuō)明，從結(jié)論來(lái)說(shuō)對(duì) Create 來(lái)說(shuō)影響會(huì)高達(dá)

21、到 10 倍。關(guān)于 WCDB 加 的使用，你可以參考 移動(dòng)數(shù)據(jù)庫(kù)組件 WCDB（四） Android 特性篇。3. 全文搜索的全文搜索也是一個(gè)技術(shù)導(dǎo)向的項(xiàng)目，最開(kāi)始的時(shí)候性能并不是很理想，經(jīng)常會(huì)被人“ ”。經(jīng)過(guò)幾個(gè)版本的優(yōu)化迭代，目前看效果還是非常不錯(cuò)的。最新 更新通知 加 ixuexi66資料整理不易 個(gè)人學(xué)習(xí) 倒賣(mài)關(guān)于全文搜索，你可以參考這些資料： FTS3 and FTS4 Extensions 全文搜索優(yōu)化 移動(dòng)客戶端多音字搜索關(guān)于 的這些特性，我們需要根據(jù) 的項(xiàng)目情況綜合考慮。假如某個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)并不重要，這個(gè)時(shí)候萬(wàn)分之一的數(shù)據(jù)損壞率我們并 關(guān)心。同樣是否需要使用數(shù)據(jù)庫(kù)加密，也要根據(jù)

22、 的數(shù)據(jù)是不是敏感內(nèi)容。的首先 說(shuō)，正確使用索引，正確使用事務(wù)。對(duì)于大型項(xiàng)目來(lái)說(shuō)，參與的開(kāi)發(fā) 可能有幾十幾百人，開(kāi)發(fā) 水平參差不齊，很難保證每個(gè)人都可以正確而高效地使用 ， 所以這次時(shí)候需要建立完善的 體系。1. 本地測(cè)試作為一名靠譜的開(kāi)發(fā)工程師，我們每寫(xiě)一個(gè) SQL 語(yǔ)句，都應(yīng)該先在本地測(cè)試。我們可以通過(guò) EXPLAIN QUERY PLAN 測(cè)試 SQL 語(yǔ)句的 計(jì)劃，是 掃描還是使用了索引，以 及具體使用了哪個(gè)索引等。代碼123> EXPLAIN QUERY PLAN SELECT * FROM t1 WHERE a=1 AND b>2; QUERY PLAN|-SEARCH

23、 TABLE t1 USING INDEX i2 (a=? AND b>?)關(guān)于命令行與 EXPLAIN QUERY PLAN 的使用，可以參考Command Line ShellFor以及EXPLAIN QUERY PLAN。2. 耗時(shí)本地測(cè)試過(guò)于依賴(lài)開(kāi)發(fā)的自覺(jué)性，所以很多時(shí)候我們依然需要建立線上大數(shù)據(jù)的監(jiān)控。因?yàn)閴K。集成了的源碼，所以可以非常方便地增加想要的模WCDB 增加了Trace的模塊，有以下三個(gè)接口：我們可以通過(guò)這些接口數(shù)據(jù)庫(kù) busy、損耗以及執(zhí)行耗時(shí)。耗時(shí)比較長(zhǎng)的 SQL 語(yǔ)句，需要進(jìn)一步檢查是 SQL 語(yǔ)句寫(xiě)得不好，還是需要建立索引。最新更新通知 加ixuexi66資料

24、整理不易個(gè)人學(xué)習(xí)倒賣(mài)3. 智能對(duì)于結(jié)果的只是我們演進(jìn)的第二階段，在這個(gè)階段我們依然需要人工介入分負(fù)責(zé)。析，而且需要比較有經(jīng)驗(yàn)的我們希望 SQL 語(yǔ)句的分析可以做到智能化，是完全不需要門(mén)檻的。開(kāi)源的 Matrix 里面就有一個(gè)智能化分析語(yǔ)句的工具：MatrixLint 使用質(zhì)量檢測(cè)。它根據(jù)分析 SQL 語(yǔ)句的語(yǔ)法樹(shù)，結(jié)合我們?nèi)粘?shù)據(jù)庫(kù)使用的經(jīng)驗(yàn)，抽象出索引使用不當(dāng)、select*等六大問(wèn)題。可能有同學(xué)會(huì)感嘆為什么的人可以想到這樣的方式，事實(shí)上這個(gè)思路在 MySQL 中是非常常見(jiàn)的做法。美團(tuán)也開(kāi)源了它們內(nèi)部的 SQL 優(yōu)化工具 SQLAdvisor，你可以參考這些資料：SQL在美團(tuán)的應(yīng)用美團(tuán)點(diǎn)評(píng) SQL 優(yōu)化工具 SQLAdvisor 開(kāi)源總結(jié)數(shù)據(jù)庫(kù)是一個(gè)開(kāi)發(fā)的基本功，清楚的底層機(jī)制對(duì)我們的工作會(huì)有很大的指導(dǎo)意義。掌握了數(shù)據(jù)庫(kù)并發(fā)的機(jī)制，在某些時(shí)候我們可以更好地決策應(yīng)該拆數(shù)據(jù)表還是拆數(shù)據(jù)庫(kù)。新建一個(gè)數(shù)據(jù)庫(kù)好處是可以其他庫(kù)并發(fā)或者損壞的情況，而壞處是數(shù)據(jù)庫(kù)初始化耗時(shí)以及內(nèi)存的占用。一般來(lái)說(shuō)，單獨(dú)的業(yè)務(wù)都會(huì)使用數(shù)據(jù)庫(kù)，例如專(zhuān)門(mén)的數(shù)據(jù)庫(kù)、數(shù)據(jù)庫(kù)、聊天數(shù)據(jù)庫(kù)。但是數(shù)據(jù)庫(kù)也不宜太多，我們可以有一個(gè)公共數(shù)據(jù)庫(kù)，用來(lái)存放一些相對(duì)不是太大的數(shù)據(jù)。在了解數(shù)據(jù)庫(kù)損壞的原理和概率以后，我們可以根據(jù)數(shù)據(jù)的重要程度決定是否要引入恢復(fù)機(jī)制。我還講了如何實(shí)現(xiàn)數(shù)據(jù)庫(kù)加密以及對(duì)