<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    neverend的日志

    不記錄,終將被遺忘。 一萬年太久,只爭朝夕。 他們用數字構建了整個世界。

      BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
      62 Posts :: 1 Stories :: 17 Comments :: 0 Trackbacks

    2012年2月4日 #

    在事務隔離級別設定為repeatable read的情況下,一般的select語句采取的是一致性非阻塞讀的方式。
    一致性是指在事務的范圍內讀取的數據是可重現的,不會出現不可重復讀的情況。非阻塞是指這種讀取數據的模式不會對數據上任何一種鎖,其它操作全都不會被阻塞。
    在這種模式下,事務執行讀取語句后,相關的數據會有一套副本出現,并會為這個數據副本附加一個時間戳,其它事務在這個時間戳之后執行的寫操作都不會反映到這個副本中,這種機制被稱之為多版本并發控制。
    如果用select …… lock in share mode,則不是一致性非阻塞讀,該語句會等待其它事務的寫語句提交或回滾之后再讀取數據;如果事務隔離級別設置為read committed,也不是一致性非阻塞讀,該語句會讀取其它事務提交的數據。
    posted @ 2012-04-05 11:25 neverend 閱讀(1877) | 評論 (0)編輯 收藏

    介紹下對于Mysql鎖機制的理解
    從基本概念開始:
    共享鎖
    共享鎖的代號是S,是Share的縮寫,共享鎖的鎖粒度是行或者元組(多個行)。一個事務獲取了共享鎖之后,可以對鎖定范圍內的數據執行讀操作。

    排它鎖
    排它鎖的代號是X,是eXclusive的縮寫,排它鎖的粒度與共享鎖相同,也是行或者元組。一個事務獲取了排它鎖之后,可以對鎖定范圍內的數據執行寫操作。

    假設有兩個事務t1和t2
    如果事務t1獲取了一個元組的共享鎖,事務t2還可以立即獲取這個元組的共享鎖,但不能立即獲取這個元組的排它鎖(必須等到t1釋放共享鎖之后)。
    如果事務t1獲取了一個元組的排它鎖,事務t2不能立即獲取這個元組的排共享鎖,也不能立即獲取這個元組的排它鎖(必須等到t1釋放排它鎖之后)。
     
    意向鎖
    意向鎖是一種表鎖,鎖定的粒度是整張表,分為意向共享鎖(IS)和意向排它鎖(IX)兩類。意向共享鎖表示一個事務有意對數據上共享鎖或者排它鎖。“有意”這兩個字表達的意思比較微妙,說的明白點就是指事務想干這個事但還沒真去干。舉例說明下意向共享鎖,比如一個事務t執行了這樣一個語句:select * from table lock in share model ,如果這個語句執行成功,就對表table上了一個意向共享鎖。lock in share model就是說事務t1在接下來要執行的語句中要獲取S鎖。如果t1的select * from table lock in share model執行成功,那么接下來t1應該可以暢通無阻的去執行只需要共享鎖的語句了。意向排它鎖的含義同理可知,上例中要獲取意向排它鎖,可以使用select * from table for update

    lock in share model 和 for update這兩個東西在數據率理論中還有個學名叫悲觀鎖,與悲觀鎖相對的當然還有樂觀鎖。大家可以看到各種鎖都是成雙成對出現的。關于悲觀鎖和樂觀鎖的問題暫且不表,下文再來詳述。

    鎖的互斥與兼容關系
    鎖和鎖之間的關系,要么是相容的,要么是互斥的。
    鎖a和鎖b相容是指:操作同樣一組數據時,如果事務t1獲取了鎖a,另一個事務t2還可以獲取鎖b;
    鎖a和鎖b互斥是指:操作同樣一組數據時,如果事務t1獲取了鎖a,另一個事務t2在t1釋放鎖a之前無法獲取鎖b。

    上面提到的共享鎖、排它鎖、意向共享鎖、意向排它鎖相互之前都是有兼容/互斥關系的,可以用一個兼容性矩陣表示(y表示兼容,n表示不兼容):
        X    S    IX    IS
    X  n     n    n     n
    S  n     y    n     y
    IX n     n    y     y
    IS n     y    y     y 

    兼容性矩陣為什么是這個樣子的?
    X和S的相互關系在上文中解釋過了,IX和IS的相互關系全部是兼容,這也很好理解,因為它們都只是“有意”,還處于YY階段,沒有真干,所以是可以兼容的;
    剩下的就是X和IX,X和IS, S和IX, S和IS的關系了,我們可以由X和S的關系推導出這四組關系。
    簡單的說:X和IX的=X和X的關系。為什么呢?因為事務在獲取IX鎖后,接下來就有權利獲取X鎖。如果X和IX兼容的話,就會出現兩個事務都獲取了X鎖的情況,這與我們已知的X與X互斥是矛盾的,所以X與IX只能是互斥關系。其余的三組關系同理,可用同樣的方式推導出來。

    一致性非阻塞讀

    select... lock in share mode和select ... for update的區別

    索引記錄鎖
    間隙鎖
    后碼鎖

    各種語句對應的鎖類型
    在有索引的情況下是以后碼鎖為基礎的行級鎖,在固定索引鍵查找的情況下是索引記錄鎖,在沒有可用索引的情況下上升到表鎖
    有索引的情況:
    select ... from 一致性非阻塞讀,不上鎖。在serializable隔離級別下例外,在這個隔離級別下上共享后碼鎖
    select ... from ... lock in share mode  共享后碼鎖
    select ... from ... for update 排它后碼鎖
    update .... where  排它后碼鎖
    delete from .... where 排它后碼鎖
    insert ... 排它索引記錄鎖,如果發生鍵值唯一性沖突則轉成共享鎖
    insert ... on duplicate key update ,一直都是排它鎖
    replace ... 一直都是排它鎖


    死鎖情境分析

    MVCC的理論與實現
    posted @ 2012-03-31 14:53 neverend| 編輯 收藏

    1. 優化更需要優化的SQL
    高并發低消耗 > 低并發高消耗

    2. 定位性能瓶頸
    profiling

    3. 明確的優化目標

    4. 從explain入手
    y
    5. 小結果集驅動大結果集??
    Join操作

    6. 在索引中完成排序

    7. 只取出自己需要的columns
    MySQL有兩種排序算法,盡可能使用只訪問一次數據的算法。

    8. 僅僅使用最有效的過濾條件
    索引鍵長度?

    9. 避免復雜的join和子查詢

    充分利用EXPLAIN和profiling
    profiling的使用:
    1.set profiling = 1;
    2.執行SQL;
    3.show profile;
    4.show profile [cpu, block io] for query [id];

    mysqlslap 測試sql性能
    mysqlslap --concurrency=5 --iterations=500 --query="selec
    t * from hbe_hotel" --create-schema=phoenix -uroot -p

    合理設計并使用索引
    Mysql支持的索引類型:
    1. B-tree索引 除了Archive的存儲引擎都支持
    2. Hash索引  memory和NDB支持
    3. Full-text索引 MyISAM,分詞后建立B-tree索引
    4. R-tree索引 MyISAM ,GIS系統使用

    索引的利弊
    利:提高數據檢索效率和排序、分組效率
    弊:加大更新操作的資源消耗,增加存儲空間的消耗

    如何判斷是否需要使用索引
    1. 使用較頻繁的字段應該創建索引
    2. 唯一性太差的字段不建索引 經驗值:15%
    3. 更新非常頻繁的字段不建索引
    4. where子句中不出現的字段不建索引

    單鍵索引還是組合索引?
    多方考慮,平衡優劣

    技術人員如何證明一個需求是否合理?
    1. 每次PD提出新需求的時候,要求給出該項目預期收益的量化指標。
    2. 在項目進行中,詳細記錄所有資源投入,包括人力、硬件等。
    3. 項目上線后收集數據統計實際收益值。
    4. 相關部門盡可能設計出項目投入/產出比率的計算規則,將投入/產出比公布給參與項目的所有人員。
    5. 比較實際的投入/產出比與預期值,以判定項目做的是否值得。

    posted @ 2012-03-13 07:48 neverend 閱讀(358) | 評論 (0)編輯 收藏

    MySQL執行計劃 

    調用方式:
    explain select ...

    explain extended select ...
    show warnings 得到MySQL優化器優化后的查詢語句

    執行計劃包含的信息:


    說明:
    id: select子句的優先級,id越大,優先級越高。
    select_type: 查詢類型
    table: 查詢的表名
    type:  MySQL找到所需行使用的方式,包括如下類型:


    ALL: 掃描全表
    index: 掃描全部索引樹
    range: 掃描部分索引
    ref: 非唯一性索引掃描
    eq_ref:唯一性索引掃描
    const, system: MySQL對查詢某部分進行優化,并轉換為一個常量時,使用這些類型訪問
    NULL: MySQL在優化過程中分解語句,執行時甚至不用訪問表或索引

    rows: 找到所需記錄需要讀取的行數
    Extra: 額外信息

    執行計劃可用來分析select語句的性能,排查性能瓶頸。

    參考資料:
    http://wenku.baidu.com/view/d4416c27aaea998fcc220ea7.html

    /Files/neverend/mysqlexplain-MySQL執行計劃解讀.ppt
    posted @ 2012-02-04 18:33 neverend 閱讀(721) | 評論 (0)編輯 收藏

    頭疼的SVN代碼merge問題

    如何merge代碼?
    建議用命令搞merge,客戶端圖形界面不是很給力。
    SVN 1.5以上版本,可以使用SVN的自動合并:
    將主干合并到分支:
    進入分支目錄,執行命令: svn merge http://server/dir/trunk

    將分支合并到主干:
    進入主干目錄,執行命令: svn merge http://server/dir/branch  --reintegrate
    注: 如果之前進行過主干合并到分支的操作,請加參數--reintegrate,否則可能會有很多代碼沖突出現。

    如果是SVN1.5以下版本,只能使用手工合并:
    進入主干目錄,執行命令:svn merge -r version1:version2 http://server/dir/branch
    將branch上從version1到version2所做的改動合并到主干,vension1 < version2

    進入主干目錄,執行命令: svn merge -c version1 http://server/dir/branch
    表示將version1次所做的改動合并到主干

    代碼沖突如何解決?

    conficted

    tree conficted
    posted @ 2012-02-04 18:13 neverend 閱讀(2078) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: 国产又大又长又粗又硬的免费视频| 亚洲国产成人久久精品动漫| 四虎永久在线观看免费网站网址 | 日本19禁啪啪无遮挡免费动图| 在线视频免费观看www动漫| 99免费观看视频| 香蕉免费一级视频在线观看| 日韩a级无码免费视频| 老司机精品免费视频| 最近高清中文字幕免费| 卡一卡二卡三在线入口免费| 亚洲欧洲日产国码一级毛片| 日韩亚洲AV无码一区二区不卡 | 亚洲精华国产精华精华液好用| 亚洲手机中文字幕| 亚洲黄色三级网站| 亚洲经典千人经典日产| 97在线视频免费公开视频| 男女免费观看在线爽爽爽视频| 国产精品另类激情久久久免费| 亚洲精品无码高潮喷水在线| 亚洲一本之道高清乱码| 日韩精品视频在线观看免费| 久久久久久久99精品免费观看| 18禁超污无遮挡无码免费网站国产 | 亚洲人成无码www久久久| 亚洲AⅤ视频一区二区三区 | 国产卡一卡二卡三免费入口| 亚洲M码 欧洲S码SSS222| 久久精品国产亚洲av麻豆色欲| 狼人大香伊蕉国产WWW亚洲 | 亚洲风情亚Aⅴ在线发布| 国产又黄又爽胸又大免费视频| 免费看成人AA片无码视频羞羞网| 亚洲国产精品一区二区三区久久 | 精品亚洲麻豆1区2区3区| 国产精品亚洲一区二区三区久久 | 免费无码一区二区三区蜜桃| 午夜无遮挡羞羞漫画免费| 亚洲精品国产精品乱码视色 | 日日麻批免费40分钟日本的|