首先是回答上次的問題。
假設有這麼一組資料，性別有4種，user_id是一對多的關係，如果我想查詢
select*fromtabwhereuser_idin(?,?,?,?)and性別=』不明』
如何進行索引構建能夠獲得比較好的效果呢？
我個人認為，應該建立的是以user_id作為前導列，性別作為輔助列的索引，在大量單值查詢時會有優勢。
理由如下
1.假定總資料量為n,user_id的區分度為n/10000而性別的區分度為n/4
那麼如果以user_id作為前導列，性別作為後列，那麼查詢的複雜度為o(logn+log(n/10000))。也就是說，第一次二分查詢之後，下一次是在第一次的二分查詢的基礎上再去查詢。而如果以性別作為前導，user_id作為後列，那麼複雜度為
o(logn+log(n/4));
效率略差。
然後進入本次正題。上次介紹了關係模型，那麼這次我們來介紹一下事務。
在一切之前，我想先給自己解嘲一下。。事務我自己也沒有辦法完全融匯貫通，因為每乙個小的選擇，都會導致效果的完全不同，所以有錯請在後面一起**。
那麼我們在這裡，主要以單機事務作為入手點，然後闡述一下多機事務相關的知識點。我在這裡只是想做乙個引導，讓大家能夠對整個的知識體系有乙個基本的認識，對於細節問題，會給出一些資料，而不會直接去進行講解，因為篇幅所限.
一般來說，我們一提起事務，就會想到資料庫，確實，事務是資料庫的最重要的乙個屬性。但這似乎不是事務的本源，那麼，讓我們從更深層次去對事務進行一次思考吧：
事務，本質來說就是一組由乙個人（或機器）發起的連續的邏輯操作，共同的完成一件事情，在完成整個事情之前，其所有的改動，都不應該對其他人可見和影響。而在事務結束之後，其一切的改動，都必須「全部」「立刻」對其他的人（或機器）可見。
然後，人們為了描述這一運作,使用了四個詞彙，這也是很多面試的同學們折戟沉沙之處。j不過這個以前我也不會，後來發現，理解了以後，確實有點用，所以這裡也費一些筆墨吧。
原子性(atomicity)：也就是說，一組操作，要不就都成功，要不就都失敗。不存在中間狀態。
一致性(consistency)：一致性，也就是說，這個事務在提交或回滾的時候，對其他人（或機器）來說，資料的狀態是同一的，不會出現中間的狀態。最理想的狀態下，就是說，資料提交後，所有的更改立刻同時生效，可惜，在計算機領域，這個做不到。。因為cpu運算，磁碟寫入，記憶體寫入，都是要時間的，內部一定是個順序化的過程，所以不可能做到絕對的立刻同時生效。
所以一致性一般來說指代的是邏輯上的同時生效，比如，我要改a,b兩行資料，那麼，最簡單的一致性保證就是，對a,b加鎖，改a,b，然後對a，b解鎖。
這樣下乙個人讀到的一定是a,b的最新值啦。
（但這塊有很多種解釋，一般來說這是個最不明確的詞彙）。
隔離性(isolation)：隔離，這是面試最容易掛的乙個問題，其實我認為不怪我們，而是因為本身這個隔離性，是依託鎖來進行設計的。
我們所知道的鎖，主要有以下幾種，1.讀寫鎖，2.排他鎖
那麼這四種級別其實就和這兩種鎖的實現有關，之所以要定義四個級別，其實原因也是因為，鎖的範圍越大，並行效率越低。而範圍越小，那麼並行的效率就越高。
讀未提交：其實就是什麼鎖也沒有，所以資料的中間狀態，是可能被其他人讀到的。
讀已提交：就是讀寫鎖實現，讀鎖在查詢之後會被釋放掉，所以這樣其他人可能會更改那些被釋放了讀鎖的資料，這樣當前事務再去讀取的時候，就可能讀取到被別人修改過的資料了，所以乙個人在事務中讀取到的某個資料，可能下次讀取就變成別的資料啦。這就是不可重複讀的意思。。
可重複讀：也是個讀寫鎖實現，讀鎖會阻塞其他人（或機器）的寫，於是，只要是事務中讀取到得資料，都被加了鎖，其他人沒辦法改他們，於是就實現了可重複讀咯。
最後是序列化，就是所有都順序，乙個大鎖全部鎖住j
永續性(durability)：永續性就是，事務執行後，就丟不了了，就算是整個中國被淹了，機器都沒了，資料也不應該丟掉（不過基本做不到這個，也就是乙個機器掛了不會丟資料而已。。）所有機房沒了那資料也就沒了。。
這些講的不錯，淺顯易懂是我的最愛.
好啦，為了保證我寫的東西不會被」qing」這個大怪獸再次吃掉。。我先發這些。
海量儲存系列之三
2011年11月26日 20 05 首先是回答上次的問題。假設有這麼一組資料，性別有4種，user id是一對多的關係，如果我想查詢 select from tabwhere user id in and 性別 不明 如何進行索引構建能夠獲得比較好的效果呢？我個人認為，應該建立的是以user id作...
海量儲存系列之三 事務原理
首先是回答上次的問題。假設有這麼一組資料，性別有4種，user id是一對多的關係，如果我想查詢 select from tabwhere user id in and 性別 不明 如何進行索引構建能夠獲得比較好的效果呢？我個人認為，應該建立的是以user id作為前導列，性別作為輔助列的索引，在大...
海量儲存系列之十三
在上一章中，我們主要介紹了規則引擎中最重要的乙個部分，自動擴容，在今天的章節，我們主要還是介紹一下我們在 tddl中的工程實踐吧。首先從原理開始吧。規則引擎是什麼呢？對應在上述例子裡面，其實就是dbnum pk 3 這個規則。他的變化可能很多，比如對於一致性hash則變為乙個if else 的表示式...