mysql
**索引 **
什么是索引
一種排好序的數(shù)據(jù)結(jié)構(gòu)，幫助mysql高效獲取數(shù)據(jù) 以索引文件的形式存儲(chǔ)在磁盤(pán)上 為什么選擇B樹(shù)/B+樹(shù)結(jié)構(gòu)作為索引結(jié)構(gòu) 由于索引是以文件形式存儲(chǔ)在磁盤(pán)上，所以評(píng)價(jià)一個(gè)數(shù)據(jù)結(jié)構(gòu)作為索引的優(yōu)劣便是查找過(guò)程中磁盤(pán)I/O。
為什么不選擇二叉樹(shù)/紅黑樹(shù)/HASH？
二叉樹(shù)極端情況是一條斜線，查找還是從頭查到尾，和沒(méi)有索引一樣；紅黑樹(shù)可以自動(dòng)調(diào)節(jié)深度，數(shù)量多-深度大，查找葉子節(jié)點(diǎn)需要非常多的I/O操作；HASH只適合查找某一個(gè)，不適合范圍查找。 樹(shù)的高度越高對(duì)應(yīng)I/O磁盤(pán)操作越多。 因?yàn)榇疟P(pán)操作有磁盤(pán)尋道與旋轉(zhuǎn)，主要耗費(fèi)在尋道上，所以高度越高對(duì)應(yīng)I/O磁盤(pán)操作越多，速度越慢。
度：節(jié)點(diǎn)大小，節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)個(gè)數(shù)。
B樹(shù)特點(diǎn)：每個(gè)節(jié)點(diǎn)存儲(chǔ)多個(gè)數(shù)據(jù)，而不是單個(gè)數(shù)據(jù)，mysql默認(rèn)每個(gè)節(jié)點(diǎn)16k，節(jié)點(diǎn)存儲(chǔ)多數(shù)據(jù)，高度就會(huì)越低。 為了讓樹(shù)的高度更可控，mysql采用B樹(shù)的變種B+樹(shù)。
B+樹(shù)特點(diǎn)：非子節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)，只冗余存儲(chǔ)索引，這樣每個(gè)節(jié)點(diǎn)(16kb)存儲(chǔ)的索引會(huì)更多，即使數(shù)據(jù)量非常大樹(shù)的高度也很低，磁盤(pán)I/O操作更少。只有葉子節(jié)點(diǎn)包含索引+數(shù)據(jù)，葉子節(jié)點(diǎn)還包含了一條指針指向下一個(gè)葉子節(jié)點(diǎn)（方便遍歷/排序）。
兩種樹(shù)的數(shù)據(jù)結(jié)構(gòu)演示 https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
B樹(shù)的節(jié)點(diǎn)數(shù)據(jù)是不是越大越好
一次磁盤(pán)I/O操作=n頁(yè)(4k*n)數(shù)據(jù)，過(guò)大不能一次加載到內(nèi)存中也需要多次I/O操作，所以最好就是一個(gè)節(jié)點(diǎn)中存放一次I/O操作的數(shù)據(jù)。
索引是怎么支撐千萬(wàn)級(jí)表的快速查找
一個(gè)索引固定為8b，指針固定為6b，結(jié)構(gòu)圖見(jiàn)簡(jiǎn)書(shū)；每個(gè)節(jié)點(diǎn)是16kb，也就是每個(gè)非子節(jié)點(diǎn)節(jié)點(diǎn)大概包含1170個(gè)索引元素；子節(jié)點(diǎn)假設(shè)一行數(shù)據(jù)占1kb，每個(gè)節(jié)點(diǎn)16kb包含16條數(shù)據(jù)；那高度僅僅為3的B+樹(shù)就包含1170117016=21902400也就是2190萬(wàn)條數(shù)據(jù)。
每個(gè)節(jié)點(diǎn)占用內(nèi)存大小
show global status like 'Innodb_page_size'; 16384字節(jié)=16kb
聚集索引，非聚集索引是基于表級(jí)別的，建表的時(shí)候可以選擇。
非聚集索引-myisam引擎
索引文件.MYI與數(shù)據(jù)文件.MYD分離
主鍵索引同非主鍵索引
索引文件葉子節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)文件的文件指針，根據(jù)文件指針定位文件數(shù)據(jù)
聚集索引-innodb引擎
索引文件與數(shù)據(jù)文件不分離，索引文件本身就是數(shù)據(jù)文件.idb 葉子節(jié)點(diǎn)存儲(chǔ)完整數(shù)據(jù)
主鍵索引：葉子節(jié)點(diǎn)中存儲(chǔ)的是完整數(shù)據(jù)
非主鍵索引：葉子節(jié)點(diǎn)中存儲(chǔ)的是主鍵索引
為什么聚集索引非主鍵索引葉子節(jié)點(diǎn)存儲(chǔ)主鍵值？
保障主鍵索引與非主鍵索引之間的數(shù)據(jù)一致性，節(jié)省存儲(chǔ)空間。
為什么innodb必須有主鍵索引？并且推薦使用整型的自增主鍵？
表結(jié)構(gòu)文件本身就是按B+樹(shù)組織的一個(gè)索引結(jié)構(gòu)文件，沒(méi)有會(huì)默認(rèn)生成類似ROW_ID的虛擬主鍵。
為什么推薦整型，比較大小快，占用空間少。
自增會(huì)減少原B+樹(shù)分裂平衡等操作，自增只需要往后邊添加樹(shù)的結(jié)點(diǎn)，分裂平衡操作少。
聯(lián)合索引底層結(jié)構(gòu)是什么樣的？
聯(lián)合索引是將各個(gè)索引字段做字符串拼接后作為key，使用時(shí)作為整體進(jìn)行匹配。
最左原則：參考聯(lián)合索引的底層結(jié)構(gòu)，其是作為整體進(jìn)行匹配的，也就是會(huì)逐字段比較
原則上sql中索引字段的順序應(yīng)該是固定，但是mysql會(huì)幫我們做優(yōu)化，改變其順序。
sql優(yōu)化
慢sql定位
1.1.mysql配置my.cnf
開(kāi)啟慢sql
slow_query_log = 1
msql存放位置
slow_query_log_file = /usr/local/mysql/data/appledeMacBook-Pro-slow.log
慢sql的值大于多少秒
long_query_time = 3
日志輸出為文件
log_output=file
將所有沒(méi)有使用帶索引的查詢語(yǔ)句全部寫(xiě)到慢查詢?nèi)罩局?br> set global log_queries_not_using_indexes = 1
1.2.sql檢測(cè)平臺(tái)
2.接口效率慢（日常使用/壓測(cè)/報(bào)警）
sql優(yōu)化思路
1.是否有使用索引
2.索引是否生效
索引是否生效
通過(guò)explain執(zhí)行計(jì)劃可以查看索引是否生效
explain里邊有很多字段，一般可以看下type表的查找方式all,index,range,ref等一些級(jí)別，possible keys就是mysql根據(jù)使用的字段簡(jiǎn)單判斷了下可以使用哪些索引，key就是實(shí)際使用到的索引，key_len可以通過(guò)該字段查詢使用索引的長(zhǎng)度，典型應(yīng)用就是聯(lián)合索引場(chǎng)景可以通過(guò)key_len判斷具體使用了聯(lián)合索引的哪幾個(gè)字段。然后就是最重要的字段extra，其中經(jīng)常出現(xiàn)的有usering index使用了索引且是較優(yōu)條件，如覆蓋索引；還有usering where等信息；然后有兩個(gè)開(kāi)發(fā)人員需要密切關(guān)注的就是usering filesort以及usering template。什么意思呢，就是語(yǔ)句中出現(xiàn)了全表掃描，出現(xiàn)了臨時(shí)表。usering filesort典型場(chǎng)景就是order by，user template典型場(chǎng)景就是group by。實(shí)際上group by底層會(huì)先排序后分組，所以解決了usering filesort就相當(dāng)于解決了usering template。
我們根據(jù)sql的復(fù)雜程度將sql優(yōu)化分兩個(gè)場(chǎng)景，一為單表優(yōu)化，二為多表優(yōu)化。
首先說(shuō)單表優(yōu)化
根據(jù)場(chǎng)景索引失效一般分為兩種，查詢索引失效和排序索引失效
1.查詢索引失效總體來(lái)說(shuō)是比較簡(jiǎn)單的，無(wú)非就是錯(cuò)誤的使用了索引，如使用條件表達(dá)式，like使用通配符等等，這個(gè)比較簡(jiǎn)單就不詳細(xì)介紹了
問(wèn)題如果where a and b，a,b分別為兩個(gè)索引，此時(shí)會(huì)走到哪個(gè)索引。
不確定，如果一個(gè)索引能唯一定位，可能只走一個(gè)索引，都不能唯一定位且范圍大可能也會(huì)走兩個(gè)，具體看key字段。
2.排序索引失效就比較麻煩了，上邊介紹了會(huì)出現(xiàn)全表掃描嘛，怎么解決呢，也就是利用索引，為什么使用索引也可以解決排序呢，就是因?yàn)樗饕讓拥臄?shù)據(jù)結(jié)構(gòu)是一種排好序的數(shù)據(jù)結(jié)構(gòu)，所以可以解決排序的問(wèn)題。
2.1聯(lián)合索引usering filesort，舉例說(shuō)明聯(lián)合索引abc三個(gè)字段，where a and b order by c這就是我們想要的索引排序；如果where a and b order by d，這樣排序就會(huì)產(chǎn)生filesort；如果where a and b> order by c這樣索引就會(huì)斷，因?yàn)閎>導(dǎo)致索引不連續(xù)了；還有where a order by (b,a)這種實(shí)際mysql會(huì)進(jìn)行優(yōu)化，也會(huì)使用到索引ab；簡(jiǎn)單舉了幾個(gè)經(jīng)常出現(xiàn)的場(chǎng)景根據(jù)經(jīng)驗(yàn)可以直接定位到，實(shí)際上判斷肯定依據(jù)explain的extra字段來(lái)確認(rèn)。
2.2問(wèn)題那么usering filesort在聯(lián)合索引的場(chǎng)景就介紹完了，也就是實(shí)際上會(huì)使用最多的場(chǎng)景，還有其他如where條件與order by條件使用不同的索引導(dǎo)致全表掃描，這種解決方案根據(jù)業(yè)務(wù)和實(shí)際場(chǎng)景考慮換為聯(lián)合索引，或者各自加索引多數(shù)場(chǎng)景也可以解決。
有一個(gè)點(diǎn)需要注意，大范圍查找數(shù)據(jù)時(shí)，有時(shí)即使感覺(jué)肯定會(huì)走到索引，但是卻顯示沒(méi)有使用索引，無(wú)論是查詢還是排序，這是因?yàn)閙ysql底層會(huì)解析使用索引還是全表掃描更快，解析過(guò)程可以通過(guò)trace工具查看，如果只是想測(cè)試是否用到索引到范圍較大時(shí)加上limit分頁(yè)，效果會(huì)更明顯。
其次說(shuō)多表查詢也就是表關(guān)聯(lián)查詢
這里我直接舉一個(gè)生產(chǎn)的例子，優(yōu)化成果是從一個(gè)15s-1min的慢sql優(yōu)化到了10ms-1s的這樣的一個(gè)結(jié)果。大概數(shù)據(jù)量是這樣的，一張表是商品表，一張表是品牌表，商品表包含了大約接近100w的數(shù)據(jù)，品牌表就很少了幾千的數(shù)據(jù)，sql就是商品表關(guān)聯(lián)品牌表查詢根據(jù)商品上架時(shí)間做倒序加分頁(yè)的一個(gè)sql；另一個(gè)現(xiàn)象就是由于商品表本身就有很多搜索維度，該表已經(jīng)創(chuàng)建了一些索引，其中包含了單獨(dú)的索引和聯(lián)合索引等，如商品名稱有個(gè)單獨(dú)索引，如店鋪，商品狀態(tài)，商品類型，促銷等字段有個(gè)聯(lián)合索引。整體表的狀況大體都清晰了，那么要怎么處理呢。
思路，多表拆單表，大表拆小表，解決單表優(yōu)化
我們的sql之前是goods left join brand on xxx where 各種條件 order by xxx limit 10，那我們兩個(gè)表關(guān)聯(lián)查詢時(shí)候只是只是結(jié)果關(guān)聯(lián)了品牌的一些信息，所有查詢的邏輯都是在商品表上邊呢，sql慢的原因是1是查商品本身就慢，2是商品表查出來(lái)的數(shù)據(jù)太多了，然后還要做關(guān)聯(lián)導(dǎo)致越來(lái)越慢。
那我們的第一個(gè)思路就是將這個(gè)復(fù)雜多表sql簡(jiǎn)化為簡(jiǎn)單單表sql，首先就是要去掉表關(guān)聯(lián)，我們將查詢+排序+分頁(yè)的邏輯放到商品表上，將原本很多的數(shù)據(jù)分頁(yè)為幾條數(shù)據(jù)后再關(guān)聯(lián)品牌表，sql就變?yōu)榱?goods where where 各種條件 order by xxx limit 10) goods_n left join brand on xxx，這樣一種將多表拆為單表，將大表拆為小表的一個(gè)方法，來(lái)解決表關(guān)聯(lián)leftjoin的問(wèn)題。
表關(guān)聯(lián)的問(wèn)題解決了，接下來(lái)解決單表商品表的查詢+排序+分頁(yè)的優(yōu)化。
首先分析了sql的構(gòu)成，發(fā)現(xiàn)有一些值在該場(chǎng)景是必傳的，如后臺(tái)查詢時(shí)都會(huì)查店鋪=本店鋪，商品狀態(tài)=上架/下架，商品類型=普通商品這幾個(gè)條件，之前分析表結(jié)構(gòu)是發(fā)現(xiàn)有這幾個(gè)條件的聯(lián)合索引的，那我們將sql的排序和分頁(yè)先去掉，看下查詢是否有使用到該聯(lián)合索引，測(cè)試結(jié)果顯示是可以使用到的，如果沒(méi)有使用到就要分析下是不是部分字段沒(méi)有使用到導(dǎo)致聯(lián)合索引失效，考慮去除該聯(lián)合索引的無(wú)用字段。查詢測(cè)試完畢后，加上排序測(cè)試下，發(fā)現(xiàn)出現(xiàn)了usering filesort，這時(shí)候其實(shí)解決該問(wèn)題也很簡(jiǎn)單了，在聯(lián)合索引加上排序字段上架時(shí)間，這里是因?yàn)榧词蛊渌麍?chǎng)景根據(jù)上架時(shí)間排序也是很通用的所以可以直接加，加上之后usering filesort也解決了，這時(shí)候加上分頁(yè)，在整體查詢后加上關(guān)聯(lián)品牌表，這樣的一個(gè)復(fù)雜sql就解決。
最后一點(diǎn)要補(bǔ)充的就是為什么只有后臺(tái)管理會(huì)出現(xiàn)慢sql，而我們其他場(chǎng)景也是類似的sql卻不會(huì)出現(xiàn)慢sql，是由于范圍的問(wèn)題，后臺(tái)管理大多不會(huì)傳入類似商品名稱，商品id等信息可以定位到小范圍數(shù)據(jù)，所以使用的是聯(lián)合索引且結(jié)果很多；而其他場(chǎng)景多是以查小范圍數(shù)據(jù)為主，使用的是該表的其他字段的索引如商品名稱索引，查出的結(jié)果很少，表關(guān)聯(lián)也不會(huì)有問(wèn)題。這里可以看出mysql選擇索引是很智能的，其會(huì)分析使用或不適用索引，使用哪條索引，查詢結(jié)果會(huì)更快。那mysql的具體分析情況可以通過(guò)自帶的trace工具查看。
trace工具
trace信息分幾個(gè)階段
sql準(zhǔn)備階段:顧名思義sql信息準(zhǔn)備
sql優(yōu)化階段:如聯(lián)合索引字段調(diào)整順序就是在這里,這里有幾個(gè)信息是我們需要關(guān)注的,如行數(shù)估計(jì)及選擇的執(zhí)行計(jì)劃;
訪問(wèn)成本估計(jì),1會(huì)計(jì)算全表掃描的情況,然后根據(jù)"掃描的行數(shù)"計(jì)算出查詢成本 2.會(huì)分析是否會(huì)用到索引,包含主鍵索引,其他索引,然后根據(jù)"索引使用范圍"來(lái)計(jì)算分析各個(gè)索引的查詢成本,最終根據(jù)上邊全表掃描的成本及各個(gè)索引的查詢成本來(lái)決定是否使用索引以及使用哪個(gè)索引
sql執(zhí)行階段:執(zhí)行階段內(nèi)容較少,如果使用usering filesort這里會(huì)有一些全表掃描的信息,如全表掃描的排序方式單路/雙路等排序的信息
usering filesort原理--trace工具sort_mode可以看出使用的哪種排序
單路排序:一次性取出滿足條件行的所有字段存入sort buffer,然后在sort buffer中排序
雙路排序:取出滿足條件行對(duì)應(yīng)的排序字段和主鍵id存入sort buffer,然后在sort buffer中排序,排序后根據(jù)id取原表中取出其他需要的字段
mysql通過(guò)比較max_length_for_sort_data大小和需要查詢字段大小判斷使用哪種排序模式
count選擇
count(1),count(id),count(*),count(name)選擇
以上四個(gè)sql的執(zhí)行計(jì)劃是一樣的,都是使用的非主鍵索引,執(zhí)行效率也差不多,區(qū)別只是count字段不會(huì)統(tǒng)計(jì)字段為null的數(shù)據(jù)行.
為什么mysql最終選擇非主鍵索引而不是主鍵索引呢?
因?yàn)閺乃饕Y(jié)構(gòu)分析,非主鍵索引葉子節(jié)點(diǎn)只存儲(chǔ)主鍵索引,其存儲(chǔ)的數(shù)據(jù)會(huì)少很多,所以選擇非主鍵索引,索引性能更高.
為什么選擇count()呢?*
為了防止null影響,參考阿里巴巴編程規(guī)范,選擇count(*)
表關(guān)聯(lián)算法
Nested-Loop Join算法:一次一行循環(huán)從第一張表讀取行,取出關(guān)聯(lián)字段,根據(jù)關(guān)聯(lián)字段在另一張表取出滿足條件的行,然后取出兩張表的結(jié)果合集(索引)
Block Nested-Loop Join算法:一次把第一張表的數(shù)據(jù)讀入到j(luò)oin buffer中,然后掃描第二張表,把第二張表每一行數(shù)據(jù)取出來(lái)跟join buffer中數(shù)據(jù)對(duì)比(非索引)
mysql鎖，事務(wù)，mvcc面試題
http://www.itdecent.cn/p/a26fd393f5a3
主從配置-讀寫(xiě)分離
判斷同步是否報(bào)錯(cuò)
1、查看Slave_IO_Running與Slave_SQL_Running狀態(tài)，Slave_IO_Running=YES && Slave_SQL_Running=NO說(shuō)明slave復(fù)制出錯(cuò)了
2、查看Last_Error以及Last_SQL_Error，獲取到具體的報(bào)錯(cuò)信息，獲取到具體的binlog以及position
3、通過(guò)binlog及posttion到主庫(kù)上，解析對(duì)應(yīng)的binlog，找到報(bào)錯(cuò)的sql。
4、解決報(bào)錯(cuò)，參考：https://blog.51cto.com/hujiangtao/1932166
如何正確判斷SLAVE的延遲情況，判定slave是否追上master的binlog：
1、首先看 Relay_Master_Log_File 和 Maser_Log_File 是否有差異；
2、如果Relay_Master_Log_File 和 Master_Log_File 是一樣的話，再來(lái)看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差異，對(duì)比SQL線程比IO線程慢了多少個(gè)binlog事件；
3、如果Relay_Master_Log_File 和 Master_Log_File 不一樣，那說(shuō)明延遲可能較大，需要從MASTER上取得binlog status，判斷當(dāng)前的binlog和MASTER上的差距；
4、如果以上都不能發(fā)現(xiàn)問(wèn)題，可使用pt_heartbeat工具來(lái)監(jiān)控主備復(fù)制的延遲。
同步方式
1.master將數(shù)據(jù)記錄到binlog中
2.slave的IO線程連接到master，并請(qǐng)求從指定日志的指定位置之后的內(nèi)容，master接收到slave的請(qǐng)求后，負(fù)責(zé)復(fù)制的IO線程會(huì)根據(jù)根據(jù)請(qǐng)求的信息從指定位置獲取日志信息+本次binlog文件名+binlong日志的位置，返回給slave
3.slave接收到返回信息后，將接收到的日志內(nèi)容添加到slave的relay-log中末尾，并將返回的binlong文件名+位置記錄到master-info中，下次同步時(shí)通過(guò)該信息獲取
4.slave的sql線程檢測(cè)到relay-log中新增了內(nèi)容后，解析為對(duì)應(yīng)的sql，在slave執(zhí)行
延時(shí)問(wèn)題
主從同步方式：同步復(fù)制，異步復(fù)制(默認(rèn))，半同步復(fù)制
同步復(fù)制：串行，性能差，金融場(chǎng)景可考慮
1.master.excute 2.master寫(xiě)入binlog 3.slave執(zhí)行db落庫(kù) 4.commit
異步復(fù)制：并行，性能高，可能會(huì)丟數(shù)據(jù)
1.master.excute 2.master寫(xiě)入binlog 3.slave執(zhí)行db落庫(kù) 3.commit
半同步復(fù)制：需要至少一次tcp調(diào)用，ack不及時(shí)(10s)，會(huì)降為異步
1.master.excute 2.master寫(xiě)入binlog 3.slave1同步relaylog 3.slave2同步relaylog 4.slave中任意一個(gè)relaylog同步完畢，則給master一個(gè)ack 4.slave并行落db 4.master接到ack后commit
商城數(shù)據(jù)庫(kù)配置
mysql：業(yè)務(wù)分庫(kù)（RDS高可用(一主一備)）+主從配置（一主一從(RDS只讀實(shí)例)），當(dāng)然這中間間隔時(shí)間是很長(zhǎng)的，怕踩坑。
項(xiàng)目：springboot多數(shù)據(jù)源配置，不同文件夾對(duì)應(yīng)不同數(shù)據(jù)源；sharding-sphere配置讀寫(xiě)分離；
為什么選擇sharding-sphere呢？經(jīng)過(guò)調(diào)研備選主要就兩個(gè)，一個(gè)是sharding-sphere，另一個(gè)是mycat，選擇sharding-sphere的原因很簡(jiǎn)單，mycat的首頁(yè)實(shí)在是太low了，就感覺(jué)不像是個(gè)官方技術(shù)首頁(yè)，而是個(gè)宗教網(wǎng)站似的，所以毅然決然的拋棄他。
關(guān)于踩坑：
關(guān)于多數(shù)據(jù)源踩坑，加了多數(shù)據(jù)源之后，就要做分布式事務(wù)，我們選擇的是Atomikos來(lái)做分布式事務(wù)，為什么選擇采用Atomikos呢？
一是基于我們業(yè)務(wù)場(chǎng)景一般都是單應(yīng)用保證這個(gè)多數(shù)據(jù)源事務(wù)；二是它業(yè)務(wù)無(wú)侵入；三是shardingsphere是支持采用Atomikos的；所以這個(gè)就成為了我們的最佳選擇。具體踩坑，中間自然經(jīng)歷了事務(wù)不回滾等坑。如Atomikos配置事務(wù)他是將我們的事務(wù)統(tǒng)一起來(lái)的的，所以我們?cè)瓉?lái)根據(jù)每個(gè)數(shù)據(jù)源定義的事務(wù)失效 TODO優(yōu)化；見(jiàn)分布式事務(wù)面試http://note.youdao.com/s/WHRO6Nho
關(guān)于讀寫(xiě)分離踩坑，自然涉及到同步出錯(cuò)，同步延時(shí)等問(wèn)題，主從http://www.itdecent.cn/p/b42776d4a804
同步延時(shí)問(wèn)題。首先，這是一個(gè)在很多場(chǎng)景幾乎無(wú)可避免的問(wèn)題。嗯，那么我們要做的是什么呢？我們可以去認(rèn)為兩種情況。
1.第一種就是頁(yè)面上的。比如。我這邊插了一條數(shù)據(jù)，然后用戶通過(guò)頁(yè)面來(lái)查看訂單的這種。這種情況即使有一些延遲。用戶也會(huì)自覺(jué)的通過(guò)刷新來(lái)查看訂單。而且一般這種延遲會(huì)很低很低。所以用戶是感知不到的。當(dāng)然，我們也可以通過(guò)硬件的手段來(lái)降低這個(gè)延遲性。這是頁(yè)面上的，這種情況。
2.另外一種情況就是我們?cè)诖a中在插入之后立即查詢的這種。這種情況如果發(fā)生，比上一種查不到這條數(shù)據(jù)的概率要高，因?yàn)榇a的運(yùn)行速度一般，肯定會(huì)小于你的這個(gè)同步延遲的這個(gè)時(shí)間的。所以我們?cè)趯?xiě)代碼的時(shí)候肯定要避免這種情況，如果我們插入一條數(shù)據(jù)，然后立即查詢這條數(shù)據(jù)，我們本身是知道的，所以多數(shù)情況我們不要這么寫(xiě)。但是肯定也有情況，會(huì)插入之后立即查詢。那這樣，我們?nèi)绻氡苊膺@個(gè)延遲問(wèn)題，只有一個(gè)方案就是去查主庫(kù)。如果使用的是shardingsphere，如shardingsphere開(kāi)啟事務(wù)的話，在你做了一次增刪改的操作后，再次查的話就是查的主庫(kù)來(lái)實(shí)現(xiàn)這個(gè)事情。這種方案結(jié)合著業(yè)務(wù)是可以參考的，因?yàn)槎鄶?shù)情況我們一般都是多表操作嘛，做統(tǒng)一變更處理是很常見(jiàn)的。
第一版關(guān)于數(shù)據(jù)源的優(yōu)化就到這里了，后續(xù)第二版我們又基于sharding-sphere做了分表，因?yàn)槲覀兪菢I(yè)務(wù)分庫(kù)嗎，所以沒(méi)有再次拆分庫(kù)，只做了分表處理。當(dāng)然這里最開(kāi)始也是只是先針對(duì)一個(gè)模塊項(xiàng)目的分表試水。其實(shí)分表踩坑也很多，如分表的維度如何選擇，分布式id，分布式事務(wù)等。
shardiing-sphere相關(guān)原理 http://note.youdao.com/s/TLJyW3HU
關(guān)于分表這里我們已經(jīng)在考慮分布式事務(wù)的問(wèn)題了，當(dāng)時(shí)應(yīng)該是1月份，當(dāng)時(shí)阿里巴巴開(kāi)源了一個(gè)分布式事務(wù)seata，當(dāng)時(shí)名字還是叫Fescar，里邊有個(gè)AT模式，我覺(jué)得真的非常實(shí)用，程序猿的福音，等到今年4月份的時(shí)候，seata正式發(fā)布了大版本1.0，我還去現(xiàn)場(chǎng)聽(tīng)了宣講會(huì)介紹，并且sharding-sphere也在四月份的時(shí)候從apache孵化成功，并且也支持了seata，兩者強(qiáng)強(qiáng)聯(lián)手，我覺(jué)得分庫(kù)分表sharding-sphere+分布式事務(wù)seata就是以后的主流。
seata-AT模式原理
見(jiàn)分布式事務(wù)面試http://note.youdao.com/s/WHRO6Nho
面試題：系統(tǒng)運(yùn)行一段時(shí)間，數(shù)據(jù)量已經(jīng)很大，這時(shí)候系統(tǒng)升級(jí)，有張表A需要增加個(gè)字段，并發(fā)量白天晚上都很大，請(qǐng)問(wèn)怎么修改表結(jié)構(gòu)
