主頁 > 軟體設計 > 記,在公司內部做的關于MySQL索引的分享

記,在公司內部做的關于MySQL索引的分享

2020-10-21 18:48:08 軟體設計

這一篇是講解Mysql中做使用到的「索引的種類」「索引正確使用的原則」「怎么優化索引」「以及兩種存盤引擎InnoDB和MyISAM索引的資料布局原理」
索引種類

在說索引之前,我們先來說一說什么是索引呢?對于索引個人的理解就是,索引是一種加快查詢資料的資料結構,

所以,索引就是一種資料結構,作用就是發揮這種資料結構的作用,加快查詢的效率,例如:InnoDB存盤引擎中使用的是就是B+tree這種資料結構來組織索引,

Mysql中索引的種類也不是很多,不同型別的索引有不同的作用,索引的作用相互之間也存在交叉關系,Mysql中索引主要分為以下幾類:

  1. 「主鍵索引」(PRIMARY KEY):主鍵索引一般都是在創建表的時候指定,「一個表只有一個主鍵索引」,特點是「唯一、非空」
  2. 「唯一索引」(UNIQUE):唯一索引具有的特點就是唯一性,可以在創建表的時候指定,也可以在創建表后創建,
  3. 「普通索引」(INDEX):普通索引唯一的作用就是加快查詢,
  4. 「組合索引」( INDEX):組合索引是創建一個「多個欄位的索引」,這個概念是相對于上上面的單列索引而言,組合索引查詢遵循「最左前綴原則」
  5. 「全文索引」(FULLTEXT):全文索引是針對一些大的「文本欄位」創建的索引,也稱為「全文檢索」
  6. 「聚簇索引」「非聚簇索引」:聚簇索引和非聚簇索引的概念比上面的概念要大,屬于包含和被包含的關系,例如:InnoDB中主鍵索引使用的就是聚簇索引,

若是你想查看一個表的所有索引,可以執行下面的sql來查看:

show index from 表名

例如,查看我自己的測驗表里面的索引,如下圖所示,Key_name表示索引的名字,Column_name表示索引的欄位,

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

上面大概的說了主要索引的概念,下面詳細的介紹一下這幾大索引的特點和使用,

主鍵索引

主鍵索引在InnoDB存盤引擎中是最常見的索引型別,一個表都會有一個主鍵索引,它索引的欄位不允許為空值,并且唯一,

一般是在創建表的時候,可以通過RIMARY KEY指定主鍵索引,在InnoDB存盤引擎中,若是創建表的時候沒有主觀創建主鍵索引,Mysql就會看表中是否有唯一索引,有,就會指定「非空的唯一索引」為主鍵索引;

沒有,就會默認生成一個6byte空間的自動增長主鍵作為主鍵索引,可以通過select _rowid from 表名查詢的是對應的主鍵值.,

MyISAM儲存引擎是可以不存在主鍵索引,MyISAM和InnoDB儲存資料的結構方式還是有明顯的區別,這個后面篇章會詳細講解,

唯一索引

唯一索引與主鍵索引的區別就是,唯一索引允許為空,若是在組合索引中,只要創建的列值是唯一的

唯一索引在實際中更多的是用來保證資料的唯一性,假如你僅僅要資料能夠快速查詢,你也可以使用普通索引,所以唯一索引重在體現它的唯一性,

實際的業務場景,有些目標欄位要求唯一,就可以使用唯一索引,創建唯一索引的方式有三種,

(1)一個是在創建表的時候指定,如下sql:

CREATE TABLE user( 
 id INT PRIMARY KEY NOT NULL, 
 name VARCHAR(16) NOT NULL, 
 UNIQUE unique_name (name(10)) 
);

(2)也可以在表創建后創建,如下sql:

CREATE UNIQUE INDEX unique_name ON user(name(10));

(3)通過修改表結構創建,如下sql:

ALTER user ADD UNIQUE unique_name ON (name(10))

這里有一個細節要注意的是創建的name欄位,指定的長度是16字符,而創建的索引的長度指定的是10字符,因為也沒有人的名字長度會超過10個字符,所以減少索引長度,能夠減少索引所占的空間的大小,

普通索引

普通索引的唯一作用就是加快資料的查詢,一般對查詢陳述句WHERE和ORDER BY后面的欄位創建普通索引,

創建普通索引的方式也有三種,基本和創建唯一索引的方式一樣,只是把關鍵字UNIQUE換成INDEX,如下所示:

// 創建表的時候創建
CREATE TABLE user( 
 id INT PRIMARY KEY NOT NULL, 
 name VARCHAR(16) NOT NULL, 
 INDEX index_name (name(10)) 
);
// 創建表后創建
CREATE INDEX INDEX index_name ON user(name(10));
// 修改表結構創建
ALTER user ADD INDEX index_name ON (name(10))

若是想洗掉索引,可以通過執行下面的sql進行洗掉索引:

DROP INDEX index_name ON user;

組合索引

組合索引即用多個欄位創建一個索引,組合索引能夠避免「回表查詢」,相對于多欄位的單列索引,組合索引的查詢效率更高,

創建組合索引(聯合索引)的方式和上面創建普通索引的方式一樣,只不過欄位的數目多了,如下sql創建:

// 其它方式和上面的一樣,這里就只列舉修改表結構的方式創建
ALTER TABLE employee ADD INDEX name_age_sex (name(10),age,sex);

回表查詢

什么是回表查詢呢?回表查詢簡單來說「通過二級索引查詢資料,得不到完整的資料行,需要再次查詢主鍵索引來獲得資料行」

InnoDB存盤引擎中,索引分為 「聚簇索引」「二級索引」,主鍵索引就是聚簇索引,其它的索引為二級索引,

聚簇索引中的葉子節點保存著完整的資料行,而二級索引的葉子節點并不是保存完整的資料行,

上面提到InnoDB表是一定要有主鍵索引的,雖然索引占據空間,但是索引符合二分查找的演算法,查找資料非常的快,

假設還是上面的employee表,里面有主鍵索引id,和普通的索引name,那么在InnoDB中就會存在兩棵B+Tree,一棵是主鍵索引樹:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

主鍵索引樹

在主鍵索引樹中的葉子節點存盤的是完整的資料行,另外一棵是name欄位的二級索引樹,如下圖所示:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

倘若你執行這條sql:select name, age, sex from employee where id ='as';就會先執行二級索引的查詢,當查詢name='as'時,得到主鍵為50,再根據主鍵查詢主鍵索引樹,得到完整的資料行,具體的執行流程如下:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

回表原理圖

這個就是回表查詢,回表查詢會查詢兩次,這樣就會降低查詢的效率,為了避免回表查詢,只查詢一次就能得到完整的資料呢?

索引覆寫

常見的方式就是「建立組合索引(聯合索引)「進行」索引覆寫」,什么是索引覆寫呢?索引覆寫就是「索引的葉子節點已經包含了查詢的資料,沒必要再回表進行查詢,」

假如我還是執行如下sql:select name, age, sex from employee where name ='as';因為普通索引只有name欄位才建立了索引,這必然會導致回表查詢,

為了提高查詢效率,就(name)「單列索引升級為聯合索引」(name, age, sex)就不同了,

因為建立的聯合索引,在二級節點的葉子階段就會同時存在name, age, sex三個的值,一次性就會獲得所需要的資料,這樣就避免了回表,但是所有的方案都不是完美的,

若是這個聯合索引哪一天某一個資料行的name值改變了或者age改變了,我就需要同時維護主鍵索引和聯合索引兩棵樹,這樣的維護成本就高了,性能開銷也大了,

相比之前資料的改變,我只需要維護主鍵索引即可,聯合索引的創建就導致了需要同時維護兩棵樹,這樣就會影響插入、更新資料的操作,所以并沒有哪種方案是完美的,

最左前綴原則

我們知道單列索引是按照索引列有序性的進行組織B+Tree結構的,聯合索引又是怎么組織B+Tree呢?

聯合索引其實也是按照創建索引的時候,最左邊的進行最開始的排序,也就是「最左前綴原則」,比如一個表中有如下資料:

nameagesexad23男bc21男bc24女bc25男de21女

如上圖所示,對于聯合索引中name欄位是放在最前面的,所以name是完全有序的,但是age欄位就不是有序的,只有當name相同,例如:name='bc'此時age欄位的索引排序才是完全有序的,

所以你會發現,在聯合索引中你只有使用以下的規則的方式查詢才會使用到索引:

  1. name,age,sex
  2. name,age
  3. name

因為Mysql的底層有查詢優化器,會判斷sql執行的時候若是使用全表掃描的效率比使用索引的效率更高,就會使用全表掃描,

假如,我查詢的時候使用age>=23,sex='男';兩個欄位作為查詢條件,但是沒有使用name欄位,因為在name不知情的條件下,對于age是無序的,

對于age>=23條件可能在很多的name不同中都有符合條件的出現,所以就沒有辦法使用索引,這也是索引實作的原因,一定要遵循「查找有序,充分的利用索引的有序性」

假如你是分別在name,age,sex三個欄位中分別建立三個單列索引,就相當于建立三顆索引樹,那么它的查詢效率,比我們使用一棵索引樹查詢效率就可想而知了,

有一種情況即使使用到了最左邊的name欄位也不會使用索引,例如:WHERE name like '%d%';這種like條件的模糊查詢是會使索引失效,

我們可以這樣理解,「查詢字串也是遵循最左前綴原則的」,字串的查詢是對字串里面的字符一個一個的匹配,「若是字串最左邊為%表示一個不確定的字串,那么是沒辦法利用到索引的有序性」

但是若是修改為 :WHERE name like 'd%';就可以使用索引,因為最左邊的字串是確定的,這種稱為「匹配列前綴」

實際業務場景中聯合索引的創建,「我們應該把識別度比較高的欄位放在前面,提高索引的命中率,充分的利用索引」

索引下推

Mysql5.6版本提出了索引下推的原則,「用于查詢優化,主要是用于like關鍵字的查詢的優化」,什么是索引下推呢?

下面通過演示來說明一下它的概念,還是利用原來的employee測驗表,假如我要執行下面的sql進行查詢:SELECT * from user where name like '張%' and age=40;

假如沒有索引下推,執行的程序如下圖所示:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

查詢會直接忽略age欄位,將name查詢的張開頭的id=5、id=7的結果回傳給Mysql服務器,再執行兩次的回表查詢,

若是上面的查詢操作使用了索引下推,執行的程序如下:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

Mysql會將查詢條件age=40的查詢條件傳遞給存盤引擎,再次過濾掉age=50的資料行,這樣回表的次數就變為了一次,提高了查詢效率,

總結起來索引下推就是在執行sql查詢的時候,會將一部分的索引列的判斷條件傳遞給存盤引擎,由存盤引擎通過判斷是否符合條件,只有符合條件的資料才會回傳給Mysql服務器,

全文索引

全文索引也稱為全文檢索,可以通過以下sql建立全文索引:ALTER TABLE employee ADD FULLTEXT fulltext_name(name);或者CREATE INDEX的方式創建,

全文索引主要是針對CHAR、VARCHAR或TEXT這種文本類的欄位有效,有人說不也可以使用like關鍵字來查詢文本嗎,

普通索引(單列索引)的查詢只能加快欄位內容中最前面的字串的檢索,若是對于多個單詞組成文本的查詢普通索引就無能為力了,

索引一經創建就沒有辦法修改,若是想要修改索引,必須重建,可以使用以下sql來洗掉索引:DROP INDEX fulltext_name ON employee;

聚簇索引和非聚簇索引

聚簇索引和非聚簇索引是相對于存盤引擎的概念,范圍比較大,包含上面所提到的索引型別,

「聚簇索引就是葉子節點中存盤的就是完整的行資料,索引和資料存盤在一起;而非聚簇索引的索引檔案和資料檔案是分開的,所以查詢資料會多一次查詢」

因此聚簇索引的查詢速度會快于非聚簇索引的查詢速度,在Mysql的存盤引擎中,「InnoDB支持聚簇索引,MyISAM不支持聚簇索引,MyISAM支持非聚簇索引」

聚簇索引

下面我們來看看InnoDB中的聚簇索引,前面說到InnoDB都會有一個主鍵,該主鍵就是用于支持聚簇索引,聚簇索引結構圖,大致如下圖所示:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

InnoDB中適用于最好的主鍵選擇就是給出一個AUTO_INCREMENT的列作為自增的主鍵,有的人可能會使用UUID作為隨機主鍵,

因為索引要維持有序性,若是使用隨機的主鍵,主鍵的插入需要尋找合適的位置進行放置,這樣維護主鍵索引樹的成本就會變得更高,

相反的,自增主鍵,主鍵都是自增變大,在維護主鍵索引樹的成本就會變得更小,所以應該盡量避免隨機主鍵,

非聚簇索引

MyISAM使用的是非聚簇索引,新插入資料的時候,會按順序的寫入的磁盤中,并且給每一行資料標記一個行號,從小逐漸增大,

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

當MyISAM創建主鍵索引的時候,形成的主鍵索引樹的結構圖如下圖所示:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

在主鍵索引中,資料也是非空且唯一,主鍵索引樹中存盤的是資料行的行號,當查詢資料的時候使用主鍵索引查詢需要查詢到行號,然后通過行號獲取資料,

非主鍵索引和主鍵索引一樣葉子節點也是存盤著行號,唯一的區別就是非主鍵索引不要求非空、唯一,

我們可以通對比圖來對比一下「InnoDB(聚簇索引)」「MyISAM(非聚簇索引)」 的索引資料布局,如下圖所示:

在公司內部做的關于MySQL索引的分享,總監說我是專家級的…

說到這里相信應該大家對于「InnoDB(聚簇索引)」「MyISAM(非聚簇索引)」 有了非常清晰的認識和理解,下面是來說一說索引的優化,這個也是和我們日常開發最密切相關的,

索引原則和優化

要正確的使用索引,就要正確的創建索引,用索引正確的查詢,不要使索引失效,因此索引的設計和優化的原則應該遵循下面的幾個原則:

  1. 索引列不要在運算式中出現,這樣會導致索引失效,如:「SELECT ...... WHERE id+1=5」;
  2. 索引列不要作為函式的引數使用,
  3. 索引列盡量不要使用like關鍵字,如:「SELECT ...... WHERE name like '%d%'」;
  4. 數字型的索引列不要當作字串型別進行條件查詢,如:「SELECT ...... WHERE id = '35'」;
  5. 盡量不要在條件NOT IN、<>、!= 中使用索引,
  6. 在索引列的欄位中不要出現NULL值,NULL值會使索引失效,可以用特殊的字符比如空字串' '或者0來代替NULL值,
  7. 聯合索引的查詢應該遵循最左前綴原則,
  8. 一般對于區別性比較大的欄位建立索引,在聯合索引中區別性比較大(識別度比較高)放在最前面,提高索引的命中率,
  9. 索引的大小要適度,不宜過大,避免索引的冗余,

總結

索引是我們作業經常會使用到的資料查詢方式,正確的使用索引可以大大提高查詢的效率,

  1. 一方面索引減少了索引服務器需要掃描的資料行的數量,將原來的全表掃描,使用特定的資料結構,能夠快速的定位資料行,
  2. 另一方面使用有序的索引,避免了排序,將原來的隨機的IO操作,變成了順序的IO操作,執行有序,

但是索引也不是十全十美的,也有自己的缺點,不正確的使用索引,將會導致索引大量的占據空間,索引并非是越多越好,索引檔案會越發的膨脹,這樣嚴重的影響查詢的性能,

對于插入、更新 、洗掉資料,除了維護資料以外,還要維護索引檔案,這樣也會影響這些操作的性能,但是對于查詢的頻率遠高于更新和插入資料的業務場景,索引是再適合不過了,

以下文章來源于非科班的科班 ,作者黎杜

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/184273.html

標籤:其他

上一篇:PHP設計模式—配接器模式

下一篇:Day23 事務***(先寫一點,以后有時間補充)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more