原文連結：

一、內連線、外連線和交叉連結

連線條件可在FROM或WHERE子句中指定，建議在FROM子句中指定連線條件。WHERE和HAVING子句也可以包含搜尋條件，以進一步篩選連線條件所選的行。

連線可分為以下幾類：

內連線取交集。外連線分為左連線、右連線和完全外部連線。左連線是左邊的全取，右連線右邊的全取。交叉連線也成為笛卡爾積，條數=列1x 列2，左表中的每一行均與右表中的所有行組合。

例子：

-------------------------------------------------
a表: id name b表: id job staff_id
1 張3 1 23 1
2 李四 2 34 2
3 王武 3 34 4
a.id同b.staff_id 存在關係

--------------------------------------------------
1）內連線
select a.*,b.* from a inner join b on a.id=b.staff_id
結果是
1 張3 1 23 1
2 李四 2 34 2

  2）左連線
select a.*,b.* from a left join b on a.id=b.staff_id
結果是
1 張3 1 23 1
2 李四 2 34 2
3 王武 null

3）右連線
select a.*,b.* from a right join b on a.id=b.staff_id
結果是
1 張3 1 23 1
2 李四 2 34 2
null 3 34 4

4）完全連線
select a.*,b.* from a full join b on a.id=b.staff_id

結果是
1 張3 1 23 1
2 李四   2 34 2
null 　　 3 34 4
3 王武 null

二、索引

索引提供指向儲存在表的指定列中的資料值的指標，是對資料庫表中一列或多列的值進行排序的一種結構。索引的實現通常使用B樹及其變種B+樹。使用索引可以快速訪問資料庫表中的特定資訊。

例如 employee 表的姓（lname）列。如果要按姓查詢特定職員，與必須搜尋表中的所有行相比，索引會幫助您更快地獲得該資訊。

唯一索引unique，保證資料的唯一性，不允許重複。比如：

UNIQUE KEY ‘user_name_unique’ (‘user_name’) USING_BTREE

單索引和組合索引，為了查詢更加快速。比如：

KEY ‘order_no_index’ (‘order_no’) USING_BTREE,

KEY ‘order_no_user_id_index’ (‘user_id’,‘order_no’) USING_BTREE

b-tree 是mysql 索引預設使用的資料結構。

給列組合增加unique約束

alter table a add CONSTRAINT [IX_a] UNIQUE ( [a1] , [vv1] );
在表a的列a1,vv1上新增UNIQUE 約束，約束名為IX_a

比如alter table T_CFG_USER_DEPOT add constraint‘User_Depot’ unique (DEPOT_ID,USER_ID);

索引佔用磁碟空間，並且降低新增、刪除和更新行的速度。作為通用規則，只有當經常查詢索引列中的資料時，才需要在表上建立索引。在多數情況下，索引用於資料檢索的速度優勢大大超過它的。

http://blog.csdn.net/kennyrose/article/details/7532032

三、Redis的五種資料型別和使用場景

Redis目前支援5種資料型別，分別是：

String（字串）
List（列表）
Hash（雜湊表）
Set（集合）
Sorted Set（有序集合）

其中：

1、String在redis內部儲存預設就是一個字串，被redisObject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

應用場景

String是最常用的一種資料型別，普通的key/value儲存都可以歸為此類，這裡就不所做解釋了。

2、Redis list的實現為一個雙向連結串列，即可以支援反向查詢和遍歷，更方便操作，不過帶來了部分額外的記憶體開銷，Redis內部的很多實現，包括髮送緩衝佇列等也都是用的這個資料結構。

應用場景

Redis list的應用場景非常多，也是Redis最重要的資料結構之一，比如twitter的關注列表、粉絲列表等都可以用Redis的list結構來實現，再比如有的應用使用Redis的list型別實現一個簡單的輕量級訊息佇列，生產者push，消費者pop/bpop。

3、Redis Hash對應Value內部實際就是一個HashMap，實際這裡會有2種不同實現，這個Hash的成員比較少時Redis為了節省記憶體會採用類似一維陣列的方式來緊湊儲存，而不會採用真正的HashMap結構，對應的value redisObject的encoding為zipmap,當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

應用場景

假設有多個使用者及對應的使用者資訊，可以用來儲存以使用者ID為key，將使用者資訊序列化為比如json格式做為value進行儲存。

4、set 的內部實現是一個 value永遠不為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

應用場景

Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要儲存一個列表資料，又不希望出現重複資料時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。

又或者在微博應用中，每個使用者關注的人存在一個集合中，就很容易實現求兩個人的共同好友功能。

5、Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證資料的儲存和有序，HashMap裡放的是成員到score的對映，而跳躍表裡存放的是所有的成員，排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的查詢效率，並且在實現上比較簡單。

使用場景

Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過使用者額外提供一個優先順序(score)的引數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set資料結構，比如twitter 的public timeline可以以發表時間作為score來儲存，這樣獲取時就是自動按時間排好序的。

又比如使用者的積分排行榜需求就可以通過有序集合實現。還有上面介紹的使用List實現輕量級的訊息佇列，其實也可以通過Sorted Set實現有優先順序或按權重的佇列。

下面就詳細分別介紹這五種資料型別及其相應的操作命令。

http://www.cnblogs.com/lizhenghn/p/5322887.html

四、找第二大的數

select * from table where order by desc limit 1,1

其中desc為降序排列，若不寫預設為asc升序排列，limit 1,1為從位置下標1處開始找1個。

五、隔離級別

資料庫提供了四種事務隔離級別, 不同的隔離級別採用不同的鎖類來實現。

READ UNCOMMITTED（未提交讀）幻想讀、不可重複讀和髒讀都允許。一個會話可以讀取其他事務未提交的更新結果，如果這個事務最後以回滾結束，這時的讀取結果就可能是不正確的，所以多數的資料庫都不會運用這種隔離級別。

READ COMMITTED（已提交讀）允許幻想讀、不可重複讀，不允許髒讀。一個會話只能讀取其他事務已提交的更新結果，否則，發生等待，但是其他會話可以修改這個事務中被讀取的記錄，而不必等待事務結束，顯然，在這種隔離級別下，一個事務中的兩個相同的讀取操作，其結果可能不同。

REPEATABLE READ（可重複讀）允許幻想讀，不允許不可重複讀和髒讀。在一個事務中，如果在兩次相同條件的讀取操作之間沒有新增記錄的操作，也沒有其他更新操作導致在這個查詢條件下記錄數增多，則兩次讀取結果相同。換句話說，就是在一個事務中第一次讀取的記錄保證不會在這個事務期間發生改動。SQL Server是通過在整個事務期間給讀取的記錄加鎖實現這種隔離級別的，這樣，在這個事務結束前，其他會話不能修改事務中讀取的記錄，而只能等待事務結束，但是SQL Server不會阻礙其他會話向表中新增記錄，也不阻礙其他會話修改其他記錄。

SERIALIZABLE（可序列化度）幻想讀、不可重複讀和髒讀都不允許。在一個事務中，讀取操作的結果是在這個事務開始之前其他事務就已經提交的記錄，SQL Server通過在整個事務期間給表加鎖實現這種隔離級別。在這種隔離級別下，對這個表的所有DML操作都是不允許的，即要等待事務結束，這樣就保證了在一個事務中的兩次讀取操作的結果肯定是相同的。SQL標準所定義的預設事務隔離級別是SERIALIZABLE。

http://blog.csdn.net/fg2006/article/details/6937413

資料庫的連線、索引和Redis的五種資料型別及其操作命令、使用場景

給列組合增加unique約束

應用場景

應用場景

應用場景

應用場景

使用場景

相關文章