在公司干活一般使用sqlserver數據庫。rownumber分頁賊好用。
但是晚上下班搞自己的事情就不用sqlserver了。原因就是自己的渣渣1核2g的小服務器完全扛不住sqlserver那么大的大塊頭，於是就使用Mysql數據庫。
一般使用MySQL分頁都是使用limit，我也這么使用的。
今天晚上打開一個服務器上的小網站，順便點幾下看看有沒有問題，不小心點到了最后一頁，卡了我近10秒才反應過來。我數據庫就7w多條數據。雖說服務器垃圾也不至於卡這么久吧。。
然后把分頁的sql找出來，去數據庫手動執行。發現確實越往后翻頁越慢，翻到四萬多條的時候，都好幾秒才響應了。這完全無法接受啊。難怪最近網站的搜索引擎權重又降低了。。5555
分頁sql如下
select id ,title,time from table where type = ‘xxx’ ORDER BY createtime limit 10 offset 45000
因為Id是主鍵，我嘗試去掉了title和time字段，馬上就秒開了。
查看數據庫執行計划，索引是已經命中了。但是為什么還是很卡呢？
查閱了不少資料，得出兩個結論
1.服務器實在是太垃圾了。
2.limit x offset x 分頁確實有性能問題，據說阿里的dba都不太建議offset太多。。。
解決方案：
既然都無法使用offset，那就曲線救國。
既然Id很快，那就先按照Id排序做分頁，查詢出一頁的Id，然后join當前表 id和Id關聯。
SELECT q.id, p.title, p.createtime from(
SELECT id from tablewhere type = @type ORDER BY createtime limit @size OFFSET @offset ) q JOIN tablep on q.id = p.id
然后使用新的這條sql，去數據庫查詢，直接就從10秒+降到了0.02秒的樣子。
並且繼續往后翻頁也不會有什么太大的性能問題。就先湊合到這里了。
好懷念工地的服務器。上百G的內存隨便揮霍。幾百萬上千萬的量都不咋優化，都跑的飛快。sqlserver收費也不是沒有道理的。不用做太多的配置。
自己干活就只能用小水管服務器。死扣細節做優化。