limit分析：
查詢分頁，limit [offset] rows ,offset 是偏移量，rows是需要的資料行數，當偏移量較大時，就會發現limit是從頭開始查詢到offset+rows，然後捨棄前面的行數返回最後的rows行，這樣在小量資料是沒有太大問題的，但是在百萬或者千萬級的資料表中進行查詢就會非常吃力，
從上面表可以看出，效率極差，即使經過優化，比如加上 「orderbyid」，使用主鍵索引進行查詢優化，經過測試表明，當偏移量較大時也是很慢，所以進來避免在2000000以上的資料表中使用。反向查詢的結果是是降序desc的，並且inputdate是記錄的插入時間，也可以用主鍵聯合索引，但是不方便。
select*fromt_limitgate3whereid
>=(selectidfromt_limitgate3limit9000000,1
)limit100
使用該語句對：
select*fromt_limitgate3limit9000000
,100
進行優化對比
由第九百萬行開始一百條
使用優化前
使用優化後
第一次執行
1:00
14.976s
第二次執行
1:00
7.332s
1鐘與14秒的差距還是很大的嘛，真的快了很多~~差不多快了4倍，
第二次執行，只用了短短的7.332s
優化前的語句第二次執行，依然是1分鐘，第二次執行測試快了相當於8倍左右，相當可以了呢！
select*fromt_limitgate3
ajoin(selectidfromt_limitgate3limit9000000
,100
)bona.id
=b.id
使用該語句對：
select*fromt_limitgate3limit9000000
,100
進行優化對比
由第九百萬行開始一百條
使用優化前
使用優化後
第一次執行
1:00
15.741s
第二次執行
1:00
16.209s
1鐘與15秒的差距也還是很大的，同樣快了很多~~差不多也是快了4倍，
第二次執行，用了短短的16.209s
優化前的語句第二次執行，依然還是1分鐘，第二次執行測試快了相當於4左右，也同樣相當可以了呢！
總結:
總的來說limit分頁查詢還是不錯的，雖然普通的未經優化的limit使用不盡人意，但是經過優化過後的確是很好用！千萬級資料也是很快的。當然這是根據業務分析的話，一般乙個頁面展示100條記錄也已經差不多！最後根據各種測試使用，limit優化過得查詢語句在資料行數超過5000條以上的資料也很慢，嘗試兩種優化查詢5000條資料均耗時17s左右，由此看來limit只是適合任意偏移量，少量行數的情況，大量的行數查詢也是不可行的。
Mysql分頁LIMIT分析
表結構 select id from table limit 2,4 返回結果 3,4,5,6 select id from table limit 3,4 返回結果 4,5,6,7 select id from table limit 3,5 返回結果 4,5,6,7,8 由以上結果可分析得到論 ...
Android wifi簡要分析
這裡列了很多，但是大致可以分為四個主要的類scanresult wificonfiguration wifiinfo wifimanager 1 scanresult，主要是通過wifi 硬體的掃瞄來獲取一些周邊的wifi 熱點的資訊。在我們進行wifi 搜尋的時候，一般會搜到這些資訊，首先是接入點...
TPLINK GPL code 簡要分析
但是無論是linux還是windows下解壓都提示壓縮包有問題，不過還是可以解壓出完整的目錄的。下面來簡要看一下裡面有什麼東西 這裡有幾個目錄，乙個個看，第乙個目錄是ap143，那麼看到裡面可以發現它是乙個標準的linux kernel，從檔名來看，它的architecture是mips。從open...