1. 快取資料庫
為了應對訪問次數多的資料如果從磁碟資料庫訪問的話消耗時間長的狀況，採用更快的快取資料庫。
redis是我的選擇，因為他是乙個開源的非關係型資料庫，將大部分資料儲存在記憶體中，並且 redis基於記憶體操作，讀寫速度很快，100000讀寫/秒，可以作為記憶體型快取伺服器，提供持久化儲存方案（通過aof的always配置）
選擇他的主要原因：
完全在記憶體中儲存資料，使用磁碟只是為了持久化
豐富的資料型別
可以將資料複製到任意數量的從伺服器中（作為集群節點時）
2.redis的啟動
redis-server 作為服務端啟動了，監聽請求
redis-client 作為客戶端啟動。
連遠端就用帶引數 -h ip
3.資料物件
重點也就是他的資料物件
資料庫鍵是乙個字串物件
值 可以: 字串物件，列表物件，雜湊物件，集合物件，有序集合物件。五種其中之一
沒用c的字串（空字元結尾），自定義了sds（****** dynamic string）作為預設字串。
2.1 sds定義
struct sdshdr2.2 並且在擴充套件字串時會進行
預分配空間和惰性空間的優化策略：
預分配用於增長操作：分配*2，超過1m時僅多分配1m
惰性空間用於空間釋放：利用free欄位來記錄儲存。
3.1 redis 的鍊錶：定義由 listnode 來定義節點（由pre 和 next）兩個指向前後為；
list 資料結構來定義
typedef struct list node
typedef struct list
2，無環，head的前節點：null；tail後節點：null；
3，快速取有長度
4，多型：鍊錶節點用 void*來儲存節點值
4.1 字典
用途：儲存鍵值對的抽象資料結構。redis的底層用字典來實現。
4.2 字典的實現
redis的字典使用雜湊表作為底層! （雜湊表）
typedef struct dictht內容： v; struct dictentry *next; } dictentry;
在union 列舉型別中，是key鍵對應的值，值可以是其中三個之一（指標，整數）而next可以來解決雜湊衝突的問題！
字典
typedef struct dict dict；type是乙個儲存了多個函式的結構體型別（有：計算雜湊值函式，複製鍵，複製值，對比鍵，銷毀鍵，銷毀值等函式）
rehashidx：這個值是記錄rehash的進度，如果-1，說明沒有進行rehash
4.3 解決鍵衝突
在dictentry裡面已經有了方法，使用開鏈的方式；並且為了速度而言，（我認為是剛存的資料使用可能性大！）將新節點放在鍊錶的開頭，
4.4 rehash
rehash是為了避免雜湊表儲存的鍵值對太多，或太少。維護負載因子的存在。對雜湊表擴充或收縮。
步驟：1，為字典的 ht[1]分配空間：如果擴充，大小為ht[0].used *2，要是2的n次方。， 否則，收縮，是ht[0].used大小就可（前提是為2的n次方）
2， 空間分配好了，ht[0]中包含的鍵值對進入ht[1]
3,遷移結束後，釋放ht[0],將ht 設定ht，在ht新建空白雜湊表。for next rehash。
漸進式rehash：是通過每次對字典執行增刪改查時，順帶將rehashidx索引上的所有鍵值對rehash到ht。完乙個+1，直到全部移過去。置rehashidx=-1
4.5總結
字典被用於實現redis的資料庫和雜湊鍵『
字典底層是雜湊表（2個！乙個使用，乙個rehash）
雜湊錶開鏈解決雜湊衝突
在對雜湊擴充套件收縮過程中，是漸進式rehash的。
02 初始資料庫
1 資料庫的建立 create database 資料庫名稱 create database shop 2 表的建立 create table 表名 列名 1 資料型別 該列所需約束 列名 2 資料型別 該列所需約束 列名 3 資料型別 該列所需約束 列名 4 資料型別 該列所需約束 該錶的約束 1...
資料庫筆記02
ps 本文章只是自己的筆記，不喜勿噴 若發現問題還請私信我，謝謝 這個其實是查詢不做修改，關鍵字distinct，distinct只能放在最前面 多個字段查詢的時候，含有distinct的字段的需要放在最前面 語法 select distinct 欄位名1,欄位2.from 表名 其可能可以實現多個...
資料庫的選擇
主流資料庫簡介 當今市面上的資料庫產品眾多，每種資料庫都有自己的優勢和缺點，或出於資料庫的效能和易用性考慮，或出於商用和開源考慮，如何選擇自己合適的資料庫產品，成為重中之重！主要的資料庫產品有如下幾種 oracle 作為一種商業性資料庫，在事務處理方面有自己獨到的優勢，功能比較強大，市場占有率也比較...