作为数据库核心成员，如何让淘宝不卡顿？
時(shí)間倒轉(zhuǎn)穿越回2007年年底
一覺(jué)醒來(lái)，我還是照常去上班，走到西溪濕地附近，馬路沒(méi)有，高樓沒(méi)有，有的是小山坡和金色的稻田。一番打聽(tīng)之后，才知道此時(shí)沒(méi)有什么西溪園區(qū)。沒(méi)辦法，硬著頭皮去濱江上班，一刷卡，才發(fā)現(xiàn)我并不是我，我現(xiàn)在的身份是淘寶數(shù)據(jù)庫(kù)團(tuán)隊(duì)的核心成員。
此時(shí)全國(guó)上下在迎接著奧運(yùn)的到來(lái)，一片祥和。淘寶網(wǎng)成交額突破400億，日活用戶達(dá)1000萬(wàn)。工程師們都非常興奮，磨刀霍霍。但是也遇到了棘手的問(wèn)題。
一 分析當(dāng)前的現(xiàn)狀
1.1 現(xiàn)有業(yè)務(wù)背景
- 淘寶網(wǎng)給中國(guó)市場(chǎng)提供了全新的購(gòu)物形式，在互聯(lián)網(wǎng)的大潮下，用戶暴增，成交量暴增，公司持續(xù)飛速增長(zhǎng)。
- 截止2007年，淘寶網(wǎng)成交額突破400億，日活用戶達(dá)1000萬(wàn)。
- 全天有1000萬(wàn)用戶訪問(wèn)淘寶。而絕大多數(shù)用戶都是在網(wǎng)上逛，什么也不買(mǎi)。
1.2 當(dāng)前的問(wèn)題
1.2.1 用戶體驗(yàn)與反饋
用戶普遍反饋逛淘寶卡頓，操作延遲特別明顯。
1.2.2 分析核心原因
- 大量的用戶在瀏覽商品，并不下單。這個(gè)人數(shù)和場(chǎng)景的比例有20:1。
- 說(shuō)明：數(shù)據(jù)庫(kù)模式事務(wù)，寫(xiě)操作會(huì)對(duì)表或者行加寫(xiě)鎖，阻塞讀操作。
- 業(yè)務(wù)數(shù)據(jù)集中在一張表里，如user表。一張表里數(shù)據(jù)破幾千萬(wàn)。查詢一條數(shù)據(jù)需要好幾秒（單表數(shù)據(jù)量太大）。
- 說(shuō)明：一張表數(shù)據(jù)提升，必然會(huì)導(dǎo)致檢索變慢， 這是必然事實(shí)。不論如何加索引或者優(yōu)化都無(wú)法解決的。
- 所有表集中在一個(gè)庫(kù)里，所有庫(kù)集中在一個(gè)機(jī)器里。數(shù)據(jù)庫(kù)集中在一臺(tái)機(jī)器上，動(dòng)不動(dòng)就說(shuō)硬盤(pán)不夠了（單機(jī)單庫(kù)）。
- 說(shuō)明：所有業(yè)務(wù)共用一份物理機(jī)器資源。機(jī)器存在瓶頸：磁盤(pán)和CPU不夠用且后期拓展性不佳。
1.2.3 總結(jié)問(wèn)題
- 20:1讀寫(xiě)比例場(chǎng)景。
- 單表單庫(kù)數(shù)據(jù)量太大。
- 小型機(jī)與單機(jī)場(chǎng)景，抗不住當(dāng)前規(guī)模。
二 我要做什么？
- 如何滿足當(dāng)前每天1000萬(wàn)用戶逛淘寶的需求，且用戶體驗(yàn)好（最基本要求：響應(yīng)快）。
- 如何滿足未來(lái)有上億用戶的訪問(wèn)，甚至是同時(shí)訪問(wèn)，且用戶體驗(yàn)好（最基本要求：響應(yīng)快）。
高筑墻，廣積糧，積極做好準(zhǔn)備。
提煉核心：
- 提高數(shù)據(jù)庫(kù)操作速度。
- 同時(shí)能應(yīng)對(duì)未來(lái)規(guī)模變化。
三 我能做什么?
為實(shí)現(xiàn)以上兩大目標(biāo)，我能做什么？
3.1 提高數(shù)據(jù)庫(kù)操作速度，通用方法
提煉常見(jiàn)的通用方法：
sql優(yōu)化
- 排除語(yǔ)法問(wèn)題，爛sql
- 下推優(yōu)化
下推的目的：提前過(guò)濾數(shù)據(jù) -> 減少網(wǎng)絡(luò)傳輸、并行計(jì)算。
- 提前過(guò)濾數(shù)據(jù)
- 小表驅(qū)動(dòng)大表等
建立索引
- 查詢頻率高的熱點(diǎn)字段
- 區(qū)分度高的(DISTINCT column_name)/COUNT()，以主鍵為榜樣（1/COUNT()）
- 長(zhǎng)度小
- 盡量能覆蓋常用查詢字段
- 注意索引失效的場(chǎng)景
分庫(kù)分表
- 垂直分庫(kù)分表
- 水平分庫(kù)分表
讀寫(xiě)分離
緩存的使用
等等。
3.2 如何應(yīng)對(duì)未來(lái)的持續(xù)變化？
必須支持動(dòng)態(tài)擴(kuò)容。
必須走分布式化路線，百分百不動(dòng)搖。
3.3 結(jié)合定位，分析自己能做的
3.3.1 分析我們的架構(gòu)定位
（1）大前提
- 我們要做通用型框架，不參與業(yè)務(wù)。
- 從軟件設(shè)計(jì)原則出發(fā)，開(kāi)閉原則：對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。
說(shuō)明：大修改就意味著不穩(wěn)定，因此：我們要做到盡可能少的修改原來(lái)的代碼。在程序需要進(jìn)行拓展的時(shí)候，不能去修改原有的代碼，實(shí)現(xiàn)一個(gè)熱插拔的效果。
（2）當(dāng)前架構(gòu)現(xiàn)狀
淘寶網(wǎng)主要使用hibernate/ibatis傳統(tǒng)框架：
（3）分析我們的架構(gòu)定位
淘寶數(shù)據(jù)庫(kù)團(tuán)隊(duì)當(dāng)時(shí)使用映射框架（hibernate/ibatis）作為數(shù)據(jù)庫(kù)交互入庫(kù)，為了不讓他們修改代碼，那我們只能在ibatis/hibenate這類映射框架之下。
同時(shí)jdbc是與底層數(shù)據(jù)庫(kù)交互的Java數(shù)據(jù)庫(kù)連接驅(qū)動(dòng)程序，是基礎(chǔ)能力，我們要使用它，而不是改造它。
結(jié)論：我得把TDDL安插于ibatis/jdbc之間，于是有了第一張架構(gòu)圖：
3.4 總結(jié)，我們能做什么？
結(jié)合我們的目標(biāo)，通用方法，大前提以及架構(gòu)定位，分析下我們能做和不能做的。
不能做的：
- 索引，因?yàn)檫@個(gè)是設(shè)計(jì)階段，強(qiáng)業(yè)務(wù)相關(guān)。與大前提沖突：我們不參與業(yè)務(wù)。
能做的：
- 語(yǔ)法優(yōu)化
- 排除sql問(wèn)題
- 下推優(yōu)化
- 分表分庫(kù)（自動(dòng)水平分表，水平分庫(kù)）
- 讀寫(xiě)分離（讀寫(xiě)分離/分布式化與動(dòng)態(tài)擴(kuò)容）
四 我們?nèi)绾巫?#xff1f;
4.1 語(yǔ)法優(yōu)化
為達(dá)到語(yǔ)法優(yōu)化的目的，我們需要具備什么能力？
簡(jiǎn)單來(lái)說(shuō)：
- 我們需要認(rèn)識(shí)這個(gè)別人提交給我的sql。
- 我能拆解sql。
- 優(yōu)化與重組這個(gè)sql。
專業(yè)點(diǎn)來(lái)說(shuō)：語(yǔ)義分析能力。
- sql解析
- sql規(guī)則制定
- sql優(yōu)化
- sql重組
因此：我們需要設(shè)計(jì)一個(gè)sql解析器，sql優(yōu)化器。
4.1.1 解析器
解析器的核心是詞法分析、語(yǔ)法語(yǔ)義分析，也就是說(shuō)來(lái)了一條 select/update/insert/delete語(yǔ)句，你能認(rèn)識(shí)它，而且你知道下一步該怎么處理，同時(shí)為后面的優(yōu)化器打下基礎(chǔ)。
核心：將sql解析為一棵語(yǔ)法樹(shù)。
例：
SELECT id, member_id FROM wp_image WHERE member_id = ‘123’sql語(yǔ)法樹(shù)：
4.1.2 優(yōu)化器
核心：
- 在sql解析成sql語(yǔ)法樹(shù)后，使用sql優(yōu)化規(guī)則(1. 語(yǔ)法優(yōu)化 2. 下推優(yōu)化)， 通過(guò)對(duì)樹(shù)進(jìn)行左旋，右旋，刪除子樹(shù)來(lái)對(duì)語(yǔ)法樹(shù)進(jìn)行重構(gòu)sql語(yǔ)法樹(shù)。
- 將重構(gòu)的語(yǔ)法樹(shù)進(jìn)行遍歷得到優(yōu)化后的sql。
（1）語(yǔ)法優(yōu)化
- 函數(shù)提前計(jì)算
- 判斷永真/永假式
- 合并范圍
- 類型處理
（2）下推優(yōu)化
- Where條件下推
說(shuō)明：提前條件過(guò)濾，提前獲取數(shù)據(jù)，減少后期計(jì)算/IO/網(wǎng)絡(luò)成本。
- JOIN中非join列的條件下推
說(shuō)明：提前過(guò)濾，減輕后期join計(jì)算成本，達(dá)到“小表驅(qū)動(dòng)”的目的。
- 等值條件的推導(dǎo)
說(shuō)明：同理，提前過(guò)濾。
4.1.3 總結(jié)
- sql解析器
- 負(fù)責(zé)將sql語(yǔ)句化為sql語(yǔ)法樹(shù)。
- sql優(yōu)化器
- 負(fù)責(zé)將sql語(yǔ)法樹(shù)利用sql優(yōu)化規(guī)則，重構(gòu)sql語(yǔ)法樹(shù)。
- 將sql語(yǔ)法樹(shù)轉(zhuǎn)化為sql語(yǔ)句。
4.2 分表分庫(kù)
單庫(kù)單表的問(wèn)題：
幾年前，業(yè)務(wù)簡(jiǎn)單，應(yīng)用的數(shù)據(jù)比較少，表結(jié)構(gòu)也不復(fù)雜。只有一個(gè)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)中的表是一張完整的表。而到了今天，2007年了，業(yè)務(wù)復(fù)雜起來(lái)了，數(shù)據(jù)量爆增，單表數(shù)據(jù)破千萬(wàn)甚至上億條，一條DML語(yǔ)句，死慢死慢的。這種情況下加索引已不再有顯著的效果。
這個(gè)時(shí)候，數(shù)據(jù)庫(kù)效率瓶頸不是靠加索引，sql優(yōu)化能搞定的。
正確出路：分表分庫(kù)，通過(guò)將表拆分，來(lái)降低單表數(shù)據(jù)量，進(jìn)而提高數(shù)據(jù)庫(kù)操作效率。
分表分為：
- 垂直分表
- 水平分表
分庫(kù)分為：
- 垂直分庫(kù)
- 水平分庫(kù)
由于TDDL不參與業(yè)務(wù)，而垂直分庫(kù)分表是強(qiáng)業(yè)務(wù)相關(guān)的，因此TDDL暫不參與垂直分庫(kù)分表，只在水平分庫(kù)分表方向上努力。
4.2.1 垂直分表
垂直拆分是將一張表垂直拆成多個(gè)表。往往是把常用的列獨(dú)立成一張主表。不常用的列以及特別長(zhǎng)的列拆分成另一張拓展表。
簡(jiǎn)單垂直分表舉例
核心要素：
- 冷熱分離，把常用的列放在一個(gè)表，不常用的放在一個(gè)表。
- 大字段列獨(dú)立存放，如描述信息。
- 關(guān)聯(lián)關(guān)系的列緊密的放在一起。
它帶來(lái)的提升是：
- 為了避免IO爭(zhēng)搶并減少鎖表的幾率，查看詳情的用戶與商品信息瀏覽互不影響。
- 充分發(fā)揮熱門(mén)數(shù)據(jù)的操作效率，商品信息的操作的高效率不會(huì)被商品描述的低效率所拖累。
4.2.2 水平分表
水平分表是在同一個(gè)數(shù)據(jù)庫(kù)內(nèi)，把同一個(gè)表的數(shù)據(jù)按一定規(guī)則拆到多個(gè)表中。
簡(jiǎn)單點(diǎn)的技巧：按照枚舉類型區(qū)分。
作用總結(jié)：
- 庫(kù)內(nèi)的水平分表，解決了單一表數(shù)據(jù)量過(guò)大的問(wèn)題，分出來(lái)的小表中只包含一部分?jǐn)?shù)據(jù)，從而使得單個(gè)表的數(shù)據(jù)量變小，提高檢索性能。
- 避免IO爭(zhēng)搶并減少鎖表的幾率。
4.2.3 垂直分庫(kù)
垂直分庫(kù)是指按照業(yè)務(wù)將表進(jìn)行分類，分布到不同的數(shù)據(jù)庫(kù)上面，每個(gè)庫(kù)可以放在不同的服務(wù)器上，它的核心理念是專庫(kù)專用。
作用總結(jié)：
- 解決業(yè)務(wù)層面的耦合，業(yè)務(wù)清晰。
- 高并發(fā)場(chǎng)景下，垂直分庫(kù)一定程度的提升IO、數(shù)據(jù)庫(kù)連接數(shù)、降低單機(jī)硬件資源的瓶頸。
- 能對(duì)不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行分級(jí)管理、維護(hù)、監(jiān)控、擴(kuò)展等。
- 垂直分庫(kù)通過(guò)將表按業(yè)務(wù)分類，然后分布在不同數(shù)據(jù)庫(kù)，并且可以將這些數(shù)據(jù)庫(kù)部署在不同服務(wù)器上，從而達(dá)到多個(gè)服務(wù)器共同分?jǐn)倝毫Φ男Ч?#xff0c;但是依然沒(méi)有解決單表數(shù)據(jù)量過(guò)大的問(wèn)題。
4.2.4 水平分庫(kù)(TDDL 核心)
水平分庫(kù)是把同一個(gè)表的數(shù)據(jù)按一定規(guī)則拆到不同的數(shù)據(jù)庫(kù)中，每個(gè)庫(kù)可以放在不同的服務(wù)器上。
作用總結(jié)：
- 解決了單庫(kù)單表數(shù)據(jù)量過(guò)大的問(wèn)題，理論上解決了高并發(fā)的性能瓶頸。
水平分庫(kù)核心要解決的問(wèn)題：
- 如何知道數(shù)據(jù)在哪個(gè)庫(kù)里？- 路由問(wèn)題
- 結(jié)果合并
- 全局唯一主鍵ID
- 分布式事務(wù)（暫時(shí)不支持）
4.2.5 水平分庫(kù)——問(wèn)題解決
（1）自動(dòng)路由算法
sql轉(zhuǎn)發(fā)：在水平拆分后，數(shù)據(jù)被分散到多張表里。原來(lái)的一個(gè)sql需要拆解，進(jìn)行轉(zhuǎn)發(fā)路由。
例：
select * from tb1 where member_id in ('test1234', 'pavaretti17', 'abcd'); => select * from tb1 where member_id in ('test1234', 'pavaretti17', 'abcd'); select * from tb1 where member_id in ('abcd');其中拆分和尋找的算法：怎么知道對(duì)應(yīng)哪個(gè)表？即自動(dòng)路由算法。常見(jiàn)的有：固定哈希算法和一致性哈希算法。
a）固定哈希算法
b）一致性哈希算法
一致性哈希算法在1997年由麻省理工學(xué)院提出，是一種特殊的哈希算法，目的是解決分布式緩存的問(wèn)題。
一致性哈希算法的優(yōu)勢(shì)：
- 極好的應(yīng)對(duì)了服務(wù)器宕機(jī)的場(chǎng)景。
- 很好的支持后期服務(wù)器擴(kuò)容。
- 在引入虛擬節(jié)點(diǎn)后：能很好的平衡各節(jié)點(diǎn)的數(shù)據(jù)分布。
由于一致性哈希算法的優(yōu)勢(shì)，此算法幾乎是所有分布式場(chǎng)景下使用的方案，包括mysql的分布式、redis的分布式等。
（2） 結(jié)果合并
升華：引入fork-Join，提升操作速度（多線程并發(fā)重點(diǎn)場(chǎng)景，代碼中也很常用哦）。
- 任務(wù)拆分
- 多路并行操作
- 結(jié)果合并
（3）全局唯一主鍵
算法：基于數(shù)據(jù)庫(kù)更新＋內(nèi)存分配。在數(shù)據(jù)庫(kù)中維護(hù)一個(gè)ID，獲取下一個(gè)ID時(shí)，會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行ID=ID+100 WHERE ID=XX，拿到100個(gè)ID后，在內(nèi)存中進(jìn)行分配。
- 優(yōu)勢(shì)：簡(jiǎn)單高效。
- 缺點(diǎn)：無(wú)法保證自增順序。
例：
水平分庫(kù)分表：一拆三場(chǎng)景。 主鍵分隔值：1000。- 表1新增一條數(shù)據(jù)，于是給表1分配1000個(gè)主鍵ID， 直到它用完。
- 同理，表2、表3在新增數(shù)據(jù)時(shí)，也給它們分配1000個(gè)主鍵ID。直到它用完。
- 當(dāng)它們的1000個(gè)主鍵ID用完后，繼續(xù)給它們分配1000個(gè)即可。
- 重復(fù)下去，可保證各庫(kù)表上的主鍵不重疊，唯一。
這種產(chǎn)生全局唯一id的方式相當(dāng)有效，保證基本的全局唯一特性和高性能的同時(shí)，可以對(duì)生成id的數(shù)據(jù)庫(kù)分機(jī)架分機(jī)房部署達(dá)到容災(zāi)的目的。
4.2.6 分表分庫(kù)總結(jié)
架構(gòu)師角度：
- 優(yōu)先考慮緩存降低對(duì)數(shù)據(jù)庫(kù)的讀操作。
- 再考慮讀寫(xiě)分離，降低數(shù)據(jù)庫(kù)寫(xiě)操作。
- 最后開(kāi)始數(shù)據(jù)拆分，切分模式：首先垂直（縱向）拆分、再次水平拆分。
- 首先考慮按照業(yè)務(wù)垂直拆分。
- 再考慮水平拆分：先分庫(kù)(設(shè)置數(shù)據(jù)路由規(guī)則，把數(shù)據(jù)分配到不同的庫(kù)中)。
- 最后再考慮分表，單表拆分到數(shù)據(jù)1000萬(wàn)以內(nèi)。
個(gè)人開(kāi)發(fā)角度：
- 優(yōu)先使用分表分庫(kù)框架（直接使用）。
- 優(yōu)先考慮緩存降低對(duì)數(shù)據(jù)庫(kù)的讀操作。
- 自己垂直分表。
- 自己水平分表。
之所以先垂直拆分才水平拆分，是因?yàn)榇怪辈鸱趾髷?shù)據(jù)業(yè)務(wù)清晰而且單一，更加方便指定水平的標(biāo)準(zhǔn)。
4.3 分布式化
分布式化是大潮，是大規(guī)模服務(wù)器最后都要走的一步。
4.3.1 讀寫(xiě)分離
設(shè)計(jì)讀寫(xiě)分離的數(shù)據(jù)庫(kù)，有兩大意義：
- 主從只負(fù)責(zé)各自的寫(xiě)和讀，極大程度的緩解X鎖和S鎖的競(jìng)爭(zhēng)。
- 從庫(kù)可配置myisam引擎，提升查詢性能以及節(jié)約系統(tǒng)開(kāi)銷。
說(shuō)明：myisam查詢效率高于默認(rèn)的innodb效率。參考：myisam和innodb的區(qū)別。
核心問(wèn)題：
- 數(shù)據(jù)的備份同步問(wèn)題：參考4.4.3。
- 讀寫(xiě)比例支持動(dòng)態(tài)設(shè)置：結(jié)合業(yè)務(wù)，如淘寶可設(shè)置為20:1。
4.3.2 容災(zāi)
主備倒換：提高可靠性 > 應(yīng)對(duì)個(gè)別數(shù)據(jù)庫(kù)宕機(jī)場(chǎng)景，尤其主庫(kù)宕機(jī)。
說(shuō)明：DB2主庫(kù)宕機(jī)后，自動(dòng)將主庫(kù)轉(zhuǎn)為DB3。
核心問(wèn)題：
- 數(shù)據(jù)的備份同步問(wèn)題：binlog 參考4.4.3。
- 檢測(cè)數(shù)據(jù)庫(kù)的在線狀態(tài)：心跳機(jī)制。
4.3.3 數(shù)據(jù)備份與同步
當(dāng)只有單機(jī)或者一份數(shù)據(jù)時(shí)，一但數(shù)據(jù)庫(kù)出問(wèn)題，那么整體服務(wù)將不可用，而且更嚴(yán)重的是會(huì)造成數(shù)據(jù)損害丟失不可逆。
在讀寫(xiě)分離與主備倒換的場(chǎng)景下，核心要解決的是多個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)同步與備份問(wèn)題。
當(dāng)前主流的是采用日志備份方式（redis也類似）。
實(shí)現(xiàn)原理：binlog日志備份。
說(shuō)明：
- 主庫(kù)負(fù)責(zé)寫(xiě)操作，在數(shù)據(jù)變更時(shí)，會(huì)寫(xiě)入binlog，同時(shí)通知各從庫(kù)。
- 從庫(kù)收到通知后，IO線程會(huì)主動(dòng)過(guò)來(lái)讀取主庫(kù)的binlog，并寫(xiě)入自己的log。
- 寫(xiě)完從庫(kù)log后，通知sql線程，sql線程讀取自己的日志，寫(xiě)入從庫(kù)。
4.3.4 動(dòng)態(tài)擴(kuò)容
動(dòng)態(tài)擴(kuò)容的意義在于：隨著后期業(yè)務(wù)量增大，數(shù)據(jù)庫(kù)個(gè)數(shù)可以通過(guò)增多的方式來(lái)應(yīng)對(duì)，而相對(duì)的改造代價(jià)很小。
擴(kuò)容前：
擴(kuò)容后：
核心內(nèi)容：
- 在添加新庫(kù)時(shí)
- 注冊(cè)機(jī)器與庫(kù)
- 路由算法調(diào)整：固定哈希算法-調(diào)整模數(shù)/一致性哈希算法天然支持?jǐn)U容
- 可選的權(quán)重調(diào)整
- 修改權(quán)重，數(shù)據(jù)插入偏向于新庫(kù)5。
- 在各庫(kù)數(shù)量平衡時(shí)，觸發(fā)修改回原來(lái)平衡的權(quán)重，以保證后續(xù)的均衡分配。
五 架構(gòu)成型
sql流向
下圖介紹sql從流入TDD到流入數(shù)據(jù)庫(kù)，期間TDDL各模塊對(duì)Sql的處理。
架構(gòu)圖
下圖介紹了TDDL三層的位置以及作用。
核心能力圖
TDDL 核心能力，核心組建示意圖，其中標(biāo)出了各模塊核心要解決功能，核心算法等。
參考
TDDL 官方文檔
http://mw.alibaba-inc.com/products/tddl/_book/
TDD產(chǎn)品原理介紹
http://gitlab.alibaba-inc.com/middleware/tddl5-wiki/raw/master/docs/Tddl_Intro.ppt
TDDL(07-10年)初始版本介紹
https://wenku.baidu.com/view/9cb630ab7f1922791788e825.html
阿里云SQL調(diào)優(yōu)指南
https://help.aliyun.com/document_detail/144293.html
一致性哈希算法原理
https://www.cnblogs.com/lpfuture/p/5796398.html
TDDL初期源碼（碼云）
https://gitee.com/justwe9891/TDDL
MyISAM與InnoDB 的區(qū)別（9個(gè)不同點(diǎn)）
https://blog.csdn.net/qq_35642036/article/details/82820178
原文鏈接：https://developer.aliyun.com/article/773227?
版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開(kāi)發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開(kāi)發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開(kāi)發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫(xiě)侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的作为数据库核心成员，如何让淘宝不卡顿？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 如何度量研发效能？
- 下一篇： 不四：产品工程师的修炼之路