分頁

之前寫php的時候，感覺分頁有點復雜，沒有搞過，結果現在天天見。。。

結果很簡單

其實想想分頁有什么就知道需要什么了

• 當前多少條——每頁頁數——pageNum
• 總共多少頁——可以說是總頁數，也可以是總條數（一般是后者）——total
• 每頁數據是哪些？——排序，以及起始位置，或者結束位置——left，start，ORDER BY

沒了

從表層看過去就這么些

然后就是具體實現，代碼不想寫，其實就是控制入參。

算好頁數，做好排序，算好每頁的起點，然后對應的發起請求就行了

高端一點呢？sql怎么寫

書 《高性能Mysql》6.7.5一節中，對LIMIT分頁的優化有具體的描述，寫的還是很令人信服的，尤其是對大分頁還是有效果的

軟件架構師需要什么

先說正確的廢話：廣度+深度

將廢話翻譯的親娘都不認識：

• 廣度：包括知識見識層面的廣度，也就是優秀的英文能力，良好的表達能力，優秀的溝通能力，優秀的技術功底，對各種技術的了解，保持對技術的熱情，甚至，對生活的熱情；
• 深度：技術上的深度，對業務的了解深度，對團隊的了解程度，對圈子環境的了解程度等；

難么，難，萬里無一的難

想當么？想

再引用一些文章吧，知乎的回答些，謝謝了

一

Daniel Mohl是一名專業的軟件工程師/架構師，他的興趣包括理解各種復雜的編程語言、企業應用架構以及如何搭建業務與技術，他通曉F#、C#、CoffeeScript、JavaScript、Erlang、ASP.NET、MVC、WPF、WCF、Sliverlight、SQL Server等技術。有著多年的軟件開發經驗。

他經常會被一些有潛力和有前途的程序員問到：“我要怎么做才能成為一名架構師？”說實話，這已經是老生常談的話題了，答案當然是視情況而定。不過他也根據自己的經驗，給大家一些建議，并且提供一些資料，助你快速走上架構師這條道路。

下面是Daniel Mohl所提出的列表，供大家參考：

首先，你必須不斷地尋求改善和提升自己。而提升自己的最好方法是閱讀，下面有幾本書，對我的軟件架構技能的提升很大。推薦給大家：

軟件架構師應該知道的97件事
企業應用架構模式
敏捷軟件開發，原則，模式和實踐
企業集成模式
JavaScript語言精髓
利用遺留代碼有效地工作
領域驅動設計
企業架構策略
設計模式（四人幫）
The Goal
SOA設計模式
SOA Principles of Service Design
除了閱讀，還有沒有其他需要注意的、或者在平時需要關注的東西呢？

每隔一兩年學習一門新語言，F#是個不錯的選擇。
選擇一個重點領域，但是盡可能對許多技術有個高層次的理解
對你所關注的重點領域，開通一個博客并且繼續拓展該領域的知識面，讓自己漸漸成為一名專家。
與不同的技術、編程語言、設計模式和結構等（甚至是它并沒有在日常中給予你直接的幫助）打交道。你永遠都不知道這些知識是否會在未來派上用場，但是對你絕對是有益無害。
根據你的目標受眾來談論“語言”。作為一名架構師，你將會與各種各樣等級的人打交道，并且他們對技術的理解也會有所不同。所以要學會調整你的講解方式，做到因人制宜，讓他們能夠理解。
閱讀博客、觀看/參加Twitter或G+、聽播客、讀雜志、參加用戶小組會議和技術會議，并且在這些會議上踴躍發言。這些都會給你帶來無窮無盡的知識和樂趣，建立自己的“品牌”和提供交流機會。
紀律是關鍵。永遠做你自己最喜歡的工作，即使它聽起來不那么有趣。每天安排時間學習一些新的東西，即使是15分鐘也可，千萬不要被其他事情占用了這段時間。
開啟博客之旅。我發現，與閱讀比起來，把東西寫下來會讓你有更深入的理解。
利用好“閑暇時間”，這段時間可以拿本雜志讀讀，或者去聽聽播客等。
了解各種可用的開發工具，可以使架構師的工作更好、更有效
看許多不同項目里的架構
學習各個項目的管理方法
學習一些評估技術，對業務可以提供有價值的評估
上面是作者總結出來的列表，雖然看起來有點枯燥無味，但在整個軟件開發過程中是樂趣無窮的。如果你還有更好的建議，歡迎與我們分享

二

多看書1.1 設計模式，重構，這兩本讓我能從程序員的視野往外走一點1.2 企業應用架構模式，領域驅動設計，比設計模式深一點，解決的也是更實際的問題1.3 人件、人月神話、夢斷代碼，理解一下軟件工程為啥會失敗2. 多看文章2.1 QCon 的就不錯，有很多架構相關的PPT，拿著一個 PPT，等對方講完問題之后，自己想想，自己的解決方案是什么？2.2 多看看各個企業的架構變化史2.3 多看看基礎組件的設計思路，比如 MySQL, Memcache, nginx, ...3. 多做3.1 做點算法題，不是為了練習算法，而是為了讓你思考更細致，畢竟少考慮一個點，肯定就無法 AC3.2 對于不同組件，自己去測試，上壓力，真實測量容量。壓死為止，看瓶頸究竟在哪兒？3.3 到線上去，看一看你的系統，哪些響應慢，不穩定。哪些資源消耗狠，需要優化或者擴容。還有多找人聊天，說出你的想法，等別人反駁，從別人的反駁中吸取知識，再去做驗證。

作者：李道兵
鏈接：https://www.zhihu.com/question/27607979/answer/37312934
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

三

作者：William Wu
鏈接：https://www.zhihu.com/question/36658435/answer/68798316
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

1：碼農分為真的能寫代碼的，以及自認為能寫代碼的。2：真的能寫代碼的碼農又分為自認為寫的不錯的，以及真的還不錯的。3：真的能寫不錯代碼的碼農又分為會鉆研會不斷優化的，以及安于現狀的。4：會鉆研的碼農又分為喜歡廣度了解新技術蜻蜓點水的，以及深入鉆研用到知識的。 了解廣度的碼農又有少部分愿意深入某些技術，喜歡深入研究的又往往缺乏廣度知識。5：極少深度廣度都關注的碼農又分為為技術而技術和為業務而技術的。 純為技術而技術的碼農在國內的軟件行業需求太少，且需求的往往不是應用軟件領域了。6：為業務而技術的深度廣度都了解的碼農，又需要有良好的溝通能力。7：而溝通好的，又有一部分當PM去了。8：然后剩下的，又有一部分慢慢脫離實際開發（不再做任何實現）或者開始依靠拿各種中間件搭積木來作為“架構”手段。9：除去這些，剩下對業務有一定了解，對技術廣度上有多種涉獵，深度上對部分技術研究徹底，還有很重要的一點，考慮問題足夠細致全面。10：細致全面善于溝通，技術上深度廣度都沒問題， 又喜歡這個工作，還會不時做底層實現，從業務和開發兩個角度出發，搭出“架構”來是為了開發效率，為了運行效率，為了開發質量，為了業務靈活和運行穩定，為了維護方便等等這樣的人，個人認為可以稱為“架構師”。而真能滿足這種需求的，別說題主的10%的比例，1%能不能達到我也持懷疑態度。其實現在的“架構師”大多數都停留在8這個層次，甚至很多在5這個層次就當上title上的架構師了。總之，成為架構師，不僅僅是工作上的簡單積累，更需要主動接納工作外的大量知識，同時，對性格上對于非技術能力上也有一定的要求，不僅如此連思維方式都很重要，外加職業發展中又有很多岔路，最后走到架構師這根樹枝上的就寥寥可數了。

轉載于:https://www.cnblogs.com/andy1202go/p/8111078.html

總結

以上是生活随笔為你收集整理的分页原理+软件架构师的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。