二、開發(fā)環(huán)境搭建
2.1、環(huán)境搭建
要運(yùn)行 Python 語句，我們需要安裝 Python解釋器。Pyton 的解釋器有多種，我們可以通過以下網(wǎng)址來下載 Python解釋器：；下載后對應(yīng)版本的安裝包后，選擇安裝目錄，安裝即可。
安裝完以后，在終端上輸入 python，進(jìn)入 Python 解釋器。出現(xiàn)如下內(nèi)容，表示 Python 解釋器安裝成功。
如果，在終端中輸入 python 后，彈出的是如下提示 或者是打開微軟應(yīng)用商店，那可能是你之前沒有勾選自動配置環(huán)境變量選項(xiàng)，需要手動配置。
右鍵此電腦圖標(biāo)，選中屬性選項(xiàng)，在彈出的菜單中選擇高級系統(tǒng)設(shè)置。選擇高級選項(xiàng)，點(diǎn)擊環(huán)境變量，在彈出的選項(xiàng)卡，點(diǎn)擊 Path 屬性，點(diǎn)擊編輯，在彈出的選項(xiàng)卡中點(diǎn)擊新建按鈕，將 Python 解釋器的安裝目錄的添加到 Path 屬性值中。
在配置環(huán)境的變量的時候，會有兩個環(huán)境變量，上面的是當(dāng)前用戶的用戶變量，下面的是系統(tǒng)的變量。用戶變量只針對當(dāng)前用戶起作用，系統(tǒng)變量對全部用戶都起作用，對于個人電腦來說，用戶變量和系統(tǒng)變量的差別不大；
2.2、Python的交互模式
當(dāng)我們輸入命令行進(jìn)入 Pyton，所進(jìn)入的界面就是 Python 的交互界面。Python 的命令提示符為三個大于號：>>>。在命令提示符后可以直接輸入 Python 的指令，輸入完的指令將會被 Python 解釋器立即執(zhí)行。
安裝 Python 的同時，默認(rèn)會安裝一個 Python 的開發(fā)工具 IDLE，通過 IDLE 也可以進(jìn)入交互模式。但是不同的是，在 IDLE 中可以通過 TAB 鍵查看語句的提示，并且它可以將代碼保存（Ctrl+S）。
交互模式只能你輸入一行，它就執(zhí)行一行，它并不適用于我們?nèi)粘５拈_發(fā)，僅可以用來作一些日常的簡單的測試。
2.3、運(yùn)行Python文件
我們可以把 Python 的語句放在一個純文本文件中，使用 Python 解釋器解釋運(yùn)行。Python 解釋器是一個應(yīng)用程序，專門用來會解釋 Python 這門語言的語法風(fēng)格并執(zhí)行的。Python 語言編寫的程序最終都是被解釋器執(zhí)行的，因此 Python 更多地是在調(diào)用 Python 解釋器地功能，所以解釋器性能地高低很大程度決定了 Python 寫出來地程序執(zhí)行效率地高低。
建議 Python 的文件以 .py 為擴(kuò)展名。如果 Python 文件以 .py 為后綴名，我們在運(yùn)行 Python 文件時，可以省略 python 命令，即只寫 文件名即可。有的電腦創(chuàng)建文件后，可能沒有顯示后綴名，我們可以通過以下方法顯示出來：
我們也可以在 IDLE 中新建一個 Python 文件，保存后運(yùn)行。
————————————————
數(shù)據(jù)庫主鍵一定要自增嗎？有哪些場景不建議自增？
你確實(shí)可以在建表sql里寫成這樣。
CREATE?TABLE?`user`?(
??`name`?char(10)?NOT?NULL?DEFAULT?''?COMMENT?'名字'
)?ENGINE=InnoDB?DEFAULT?CHARSET=utf8mb4;
看起來確實(shí)是沒有主鍵的樣子。然而實(shí)際上，mysql的innodb引擎內(nèi)部會幫你生成一個名為ROW_ID列，它是個6字節(jié)的隱藏列，你平時也看不到它，但實(shí)際上，它也是自增的。有了這層兜底機(jī)制保證，數(shù)據(jù)表肯定會有主鍵和主鍵索引。
跟ROW_ID被隱藏的列還有trx_id字段，用于記錄當(dāng)前這一行數(shù)據(jù)行是被哪個事務(wù)修改的，和一個字段，這個字段是用來指向當(dāng)前這個數(shù)據(jù)行的上一個版本，通過這個字段，可以為這行數(shù)據(jù)形成一條版本鏈，從而實(shí)現(xiàn)多版本并發(fā)控制（MVCC）。有沒有很眼熟，這個在之前寫的里出現(xiàn)過。
隱藏的row_id列
有沒有建議主鍵不自增的場景
前面提到了主鍵自增可以帶來很多好處，事實(shí)上大部分場景下，我們都建議主鍵設(shè)為自增。
那有沒有不建議主鍵自增的場景呢？
mysql分庫分表下的id
聊到分庫分表，那我就需要說明下，遞增和自增的區(qū)別了，自增就是每次都+1，而遞增則是新的id比上一個id要大就行了，具體大多少，沒關(guān)系。
之前寫過一篇提到過，mysql在水平分庫分表時，一般有兩種方式。
一種分表方式是通過對id取模進(jìn)行分表，這種要求遞增就好，不要求嚴(yán)格自增，因?yàn)槿∧：髷?shù)據(jù)會被分散到多個分表中，就算id是嚴(yán)格自增的，在分散之后，都只能保證每個分表里id只能是遞增的。
根據(jù)id取模分表
另一種分表方式是根據(jù)id的范圍進(jìn)行分表（分片），它會劃出一定的范圍，比如以2kw為一個分表的大小，那0~2kw就放在這張分表中，2kw~4kw放在另一張分表中，數(shù)據(jù)不斷增加，分表也可以不斷增加，非常適合動態(tài)擴(kuò)容，但它要求id自增，如果id遞增，數(shù)據(jù)則會出現(xiàn)大量空洞。舉個例子，比如第一次分配id=2，第二次分配id=2kw，這時候第一張表的范圍就被打滿了，后面再分配一個id，比如是3kw，就只能存到2kw~4kw（第二張）的分表中。那我在0~2kw這個范圍的分表，也就存了兩條數(shù)據(jù)，這太浪費(fèi)了。
根據(jù)id范圍分表
但不管哪種分表方式，一般是不可能繼續(xù)用原來表里的自增主鍵的，原因也比較好理解，原來的每個表如果都從0開始自增的話，那好幾個表就會出現(xiàn)好幾次重復(fù)的id，根據(jù)id唯一的原則，這顯然不合理。
所以我們在分庫分表的場景下，插入的id都是專門的id服務(wù)生成的，如果是要嚴(yán)格自增的話，那一般會通過redis來獲得，當(dāng)然不會是一個id請求獲取一次，一般會按批次去獲得，比如一次性獲得100個。快用完了再去獲取下一批100個。
但這個方案有個問題，它嚴(yán)重依賴redis，如果redis掛了，那整個功能就傻了。
有沒有不依賴于其他第三方組件的方法呢？
雪花算法
有，比如Twitter開源的雪花算法。
雪花算法通過64位有特殊含義的數(shù)字來組成id。
雪花算法
首先第0位不用。
接下來的41位是時間戳。精度是毫秒，這個大小大概能表示個69年左右，因?yàn)闀r間戳隨著時間流逝肯定是越來越大的，所以這部分決定了生成的id肯定是越來越大的。
再接下來的10位是指產(chǎn)生這些雪花算法的工作機(jī)器id，這樣就可以讓每個機(jī)器產(chǎn)生的id都具有相應(yīng)的標(biāo)識。
再接下來的12位，序列號，就是指這個工作機(jī)器里生成的遞增數(shù)字。
可以看出，只要處于同一毫秒內(nèi)，所有的雪花算法id的前42位的值都是一樣的，因此在這一毫秒內(nèi)，能產(chǎn)生的id數(shù)量就是2的10次方??2的12次方，大概400w，肯定是夠用了，甚至有點(diǎn)多了。
但是！
細(xì)心的兄弟們肯定也發(fā)現(xiàn)了，雪花算法它算出的數(shù)字動不動就比上次的數(shù)字多個幾百幾萬的，也就是它生成的id是趨勢遞增的，并不是嚴(yán)格+1自增的，也就是說它并不太適合于根據(jù)范圍來分表的場景。這是個非常疼的問題。
還有個小問題是，那10位工作機(jī)器id，我每次擴(kuò)容一個工作機(jī)器，這個機(jī)器怎么知道自己的id是多少呢？是不是得從某個地方讀過來。
那有沒有一種生成id生成方案，既能讓分庫分表能做到很好的支持動態(tài)擴(kuò)容，又能像雪花算法那樣并不依賴redis這樣的第三方服務(wù)。
有。這就是這篇文章的重點(diǎn)了。
適合分庫分表的uuid算法
我們可以參考雪花算法的實(shí)現(xiàn)，設(shè)計成下面這樣。注意下面的每一位，都是十進(jìn)制，而不是二進(jìn)制。
適合分庫分表的uuid算法
開頭的12位依然是時間，但并不是時間戳，雪花算法的時間戳精確到毫秒，我們用不上這么細(xì)，我們改為，注意開頭的yy是兩位，也就是這個方案能保證到2099年之前，id都不會重復(fù)，能用到重復(fù)，那也是真·百年企業(yè)。同樣由于最前面是時間，隨著時間流逝，也能保證id趨勢遞增。
接下來的10位，用十進(jìn)制的方式表示工作機(jī)器的ip，就可以把12位的ip轉(zhuǎn)為10位的數(shù)字，它可以保證全局唯一，只要服務(wù)起來了，也就知道自己的ip是多少了，不需要像雪花算法那樣從別的地方去讀取worker id了，又是一個小細(xì)節(jié)。
在接下來的6位，就用于生成序列號，它能支持每秒鐘生成100w個id。
最后的4位，也是這個id算法最妙的部分。它前2位代表分庫id，后2位代表分表id。也就是支持一共100*100=1w張分表。
舉個例子，假設(shè)我只用了1個分庫，當(dāng)我一開始只有3張分表的情況下，那我可以通過配置，要求生成的uuid最后面的2位，取值只能是[0,1,2]，分別對應(yīng)三個表。這樣我生成出來的id，就能非常均勻的落到三個分表中，這還順帶解決了單個分表熱點(diǎn)寫入的問題。
如果隨著業(yè)務(wù)不斷發(fā)展，需要新加入兩張新的表(3和4)，同時第0張表有點(diǎn)滿了，不希望再被寫了，那就將配置改為[1,2,3,4]，這樣生成的id就不會再插入到對應(yīng)的0表中。同時還可以加入生成id的概率和權(quán)重來調(diào)整哪個分表落更多數(shù)據(jù)。
有了這個新的uuid方案，我們既可以保證生成的數(shù)據(jù)趨勢遞增，同時也能非常方便擴(kuò)展分表。非常nice。
數(shù)據(jù)庫有那么多種，mysql只是其中一種，那其他數(shù)據(jù)庫也是要求主鍵自增嗎？
tidb的主鍵id不建議自增
tidb是一款分布式數(shù)據(jù)庫，作為mysql分庫分表場景下的替代產(chǎn)品，可以更好的對數(shù)據(jù)進(jìn)行分片。
它通過引入Range的概念進(jìn)行數(shù)據(jù)表分片，比如第一個分片表的id在0~2kw，第二個分片表的id在2kw~4kw。這其實(shí)就是根據(jù)id范圍進(jìn)行數(shù)據(jù)庫分表。
它的語法幾乎跟mysql一致，用起來大部分時候是無感的。
但跟mysql有一點(diǎn)很不一樣的就是，mysql建議id自增，但tidb卻建議使用隨機(jī)的uuid。原因是如果id自增的話，根據(jù)范圍分片的規(guī)則，一段時間內(nèi)生成的id幾乎都會落到同一個分片上，比如下圖，從3kw開始的自增uuid，幾乎都落到range 1這個分片中，而其他表卻幾乎不會有寫入，性能沒有被利用起來。出現(xiàn)一表有難，多表圍觀的場面，這種情況又叫寫熱點(diǎn)問題。
寫熱點(diǎn)問題
所以為了充分的利用多個分表的寫入能力，tidb建議我們寫入時使用隨機(jī)id，這樣數(shù)據(jù)就能被均勻分散到多個分片中。
用戶id不建議用自增id
前面提到的不建議使用自增id的場景，都是技術(shù)原因?qū)е碌模旅娼榻B的這個，單純是因?yàn)闃I(yè)務(wù)。
舉個例子吧。
如果你能知道一個產(chǎn)品每個月，新增的用戶數(shù)有多少，這個對你來說會是有用的信息嗎？
對程序員來說，可能這個信息價值不大。
但如果你是做投資的呢，或者是分析競爭對手呢？
那反過來。
如果你發(fā)現(xiàn)你的競爭對手，總能非常清晰的知道你的產(chǎn)品每個月新進(jìn)的注冊用戶是多少人，你會不會心里毛毛的？
如果真出現(xiàn)了這問題，先不要想是不是有內(nèi)鬼，先檢查下你的用戶表主鍵是不是自增的。
如果用戶id是自增的，那別人只要每個月都注冊一個新用戶，然后抓包得到這個用戶的user_id，然后跟上個月的值減一下，就知道這個月新進(jìn)多少用戶了。
同樣的場景有很多，有時候你去小店吃飯，發(fā)票上就寫了你是今天的第幾單，那大概就能估計今天店家做了多少單。你是店家，你心里也不舒服吧。
再比如說一些小app的商品訂單id，如果也做成自增的，那就很容易可以知道這個月成了多少單。
類似的事情有很多，這些場景都建議使用趨勢遞增的uuid作為主鍵。
當(dāng)然，主鍵保持自增，但是不暴露給前端，那也行，那前面的話，你當(dāng)我沒說過。
總結(jié)
1、
2、
3、
4、
5、
