今天我們來聊聊SQL崔列，關于SQL我一開始的想法是，我知道select旺遮，update峻呕，delete，insert就可以了趣效，其實對于測試瘦癌，日常工作中我們差不多用到這幾項SQL語句。前幾天我發(fā)現(xiàn)數(shù)據(jù)庫中有個表數(shù)據(jù)太多跷敬，想要把表清空讯私，我自然而然的就執(zhí)行了DELETE FROM XXX，然后我就悲劇了西傀，數(shù)據(jù)表被鎖死了斤寇。請教了開發(fā)之后，才了解到拥褂，這個表數(shù)據(jù)太多大概有12G娘锁，使用delete性能會很慢，而且這個表一直被訪問饺鹃，當你清空的時候會導致數(shù)據(jù)表死鎖莫秆。這個時候才知道自己對于SQL的了解真的很淺，先記錄下開發(fā)大大提供的解決方法：1悔详、create table xxx_new like xxx; 2镊屎、alter table xxx rename to xxx_old; 3、alter table xxx_new rename to xxx; 4茄螃、drop table xxx_old;(truncate table xxx)缝驳。
為了很好去了解開發(fā)大大給的SQL語句，特意去百度了一下归苍，記錄下delete用狱，drop，truncate的區(qū)別：1拼弃、從執(zhí)行速度上來說：drop>truncate>delete夏伊；2、truncate和delete只是刪除表里面的數(shù)據(jù)肴敛，而drop是把整個表的結(jié)構也一起刪除了署海；3吗购、delete是可以回滾的，而truncate和drop是data define language是不能回滾的砸狞；
在日常寫select的時候捻勉，有時會發(fā)現(xiàn)搜索很慢，然后這個時候去查看數(shù)據(jù)庫刀森，發(fā)現(xiàn)我的where里面沒有索引字段踱启。那么問題來了什么是索引，我們經(jīng)常會聽開發(fā)說起索引研底，但是對索引卻是一知半解埠偿。為什么要建索引？有一次我用查詢一個表根據(jù)表的title字段搜索（where titile=”XXX”）榜晦，然后等了2分鐘還沒出結(jié)果冠蒋，特納悶。然后我看了下表結(jié)構乾胶，索引里面沒有title這一項抖剿，而且表有12G（沒錯就是我上面要刪除的那個表），然后我換了一個搜索方式识窿，根據(jù)里面索引字段搜索斩郎，一共40S就出來了，這就是為啥要建立索引喻频。而對于我們測試來說缩宜，知道索引更多的是了解下數(shù)據(jù)庫的性能，如果可以的話甥温，我們可以查看下開發(fā)常用的查詢SQL的字段是否加了索引（然而并不是所有字段的查詢都需要加索引锻煌，更多的要根據(jù)具體業(yè)務來講），關于數(shù)據(jù)庫性能更深入的內(nèi)容后期再講窿侈。
之前我在出數(shù)據(jù)庫select的查詢面試題時炼幔，我涉及了一個二級查詢的題目∈芳颍“獲取room的前50個數(shù)據(jù)，先score順序肛著，再created_time倒序”圆兵，一開始以為這個算是個送分題，結(jié)果卻發(fā)現(xiàn)沒有人寫對了枢贿，一般只寫了一半殉农。但是為啥我會出這個題目，因為在日常工作中局荚，我們經(jīng)常測試到榜單超凳，對于測試來說榜單一定是個唯一序列愈污。如果一個榜單是根據(jù)score排序，那么我們要想的是如果score一樣時會怎么樣呢轮傍？我曾經(jīng)就入過這么一個坑：我和開發(fā)用同一條SQL去查詢暂雹，然而我們查詢出來的結(jié)果始終對不上，結(jié)果一查有兩條數(shù)據(jù)的score是一樣的创夜。那為啥同一個SQL語句當order那個字段的值一樣而數(shù)據(jù)會不一樣呢杭跪？我還遇到過一個問題，SQL的前面是一樣的驰吓，但是limit 2和limit 10的數(shù)據(jù)列表前兩個值得排序是不一樣的涧尿。那這又是為什么呢？SQL在查詢的時候檬贰，有自己的一套機制姑廉，它會以最快的速度查出給用戶想要的值，當你的其中一個查詢字段內(nèi)容一樣且沒有其他更多排序要求時翁涤，它就會按照最近拿到的數(shù)據(jù)返回給你庄蹋。
關于數(shù)據(jù)庫的東西有很多，很多都是在小細節(jié)上的迷雪，作為一個測試限书，我一直對自己強調(diào)的是千萬別跟著開發(fā)的思路走，要學會自我思考章咧，自己有一個清晰的思路倦西，這樣我們才能去發(fā)現(xiàn)開發(fā)邏輯中的錯誤。如果我們先聽取開發(fā)的講解赁严，很容易有了先入為主的概念扰柠，那么容易被牽著鼻子走。之前開發(fā)一直不愿意加二級查詢疼约，覺得一級就夠了絕對不會有問題卤档，后來我就用數(shù)據(jù)告訴他，就算有萬分之一的幾率重復程剥，我們也要防止這種情況出現(xiàn)（因為我們活動榜單上的排序涉及到用戶的獎勵劝枣，對于用戶比較重要）。
最后關于數(shù)據(jù)庫的內(nèi)容很多织鲸，今天先講了一些日常中遇到的坑舔腾，其他內(nèi)容后期再續(xù)。希望做測試的同伴們搂擦，在日常使用中能夠?qū)ψ约簩懙腟QL或者開發(fā)給SQL可以多多了解一番稳诚，雖然我們是測試，但是我們也可以和開發(fā)了解的一樣多瀑踢，或者比之更多扳还。
