locked
NOLOCK hatasa a performanciara RRS feed

  • Question

  • hali
    nem teljesen ertek valami a locking belso lelkivilagaban
    van egy ilyen:

    Select @TId = id from T (nolock) where name ='Alma' -- csak 1 ilyen lehet, mert a name uniq

    ez elvileg gyorsabb kene legyen mint ha nincs ott a (nolock) merthogy kevesebbet kell foglalkozni az adminisztracioval (ez egy gyakorlatilag statikus tabla csak olvassak sokan)
    mert nem kell nezni, hogy van-e logo tetl vagy nincs vagy mi merre van.
    a gyakorlati meres megis azt mutatja, hogy (nolock) nelkul gyorsabb.

    Valaki el tudja meselni, hogy miert?

    Potyos
    Wednesday, September 16, 2009 1:33 PM

All replies

  • Valószínűleg a különbség kicsi, mérési hibán belül van. Arra gondolok, hogy egyéb tényezők erősebben befolyásolják a végrehajtási időt, mint a lock/nolock.
    SQL Server 2008-on megpróbáltam igazolni, vagy inkább cáfolni az állításodat, de bárhogy mértem, túl nagy volt a szórás.

    Károly
    Wednesday, September 16, 2009 9:16 PM
  • Károlynak igaza van, mérési határon van csak selectek használatának esetén:

    Ezzel a scriptel nekem ezred másodperces különbségek  vannak egy connectionon elindítva

    nolock:
    set nocount on
    declare @date datetime=getdate()
    declare @i int=0,@max int =1000000
    
    while @i<@max
    begin
    exec x1
    set @i+=1
    end
    select GETDATE()-@date
    go


    lock:

    set nocount on
    declare @date datetime=getdate()
    declare @i int=0,@max int =1000000
    
    while @i<@max
    begin
    exec x2
    set @i+=1
    end
    select GETDATE()-@date
    go


    3 connectionon inditom őket el, akkor sem változik az eredmény nagyon:

    nolock:

    1900-01-01 00:00:55.870
    1900-01-01 00:00:36.357
    1900-01-01 00:00:55.290


    lock:

    1900-01-01 00:00:57.313
    1900-01-01 00:00:36.057
    1900-01-01 00:00:56.940



    István Sáfár
    Thursday, September 17, 2009 7:47 AM
    Moderator

  • Azt azért meg kell jegyezni, hogy a NOLOCK nem egészen azt jelenti, hogy nem kell törődni azzal, hogy más tranzakciók lockolják-e az adott táblát vagy sort. Hiszen a Sch-M (schema modification) típusu lockok a NOLOCK-al indított SELECT-eket is blokkolják.
    A NOLOCK annyit jelent, hogy a SELECT végrehajtása során a szerver nem helyez el S (shared) lockokat az egyes sorokon vagy az egész táblán (de Sch-S, azaz schema stability lockot igen).
    Viszont, hogy miért nem gyorsabb ettől a lekérdezés egyelőre én sem tudom megmondani. :(
    m@te
    Thursday, October 29, 2009 1:40 PM