系統優化可不是變魔術，或施法術（若能施法術，也不錯 :) ），一切都是實事求是
抽象地說就是將不合理的規劃、設計、開發調整為合理的規劃、設計、開發，可能涉及資料儲存結構（索引），sql**改寫，sql邏輯改寫，作業系統與資料庫配置調整，及**伺服器的快取，到業務流程的優化，對於很多場景來說，處理掉前兩三點，立桿見影的效果就出來了。基本上也遵循二八原則，就是將關鍵的20%部分處理好，問題就基本解決了。至於說要精益求精，若時間、成本、投入充足，亦是好事。
對於**應用來說，pv的響應時間是600毫秒還是200毫秒，是僅白天可用還是7*24，可能對使用者與客戶在表面上看起來並沒多大區別，就像咱們自己開啟乙個excel**，是600毫秒還是200毫秒，似乎無所謂一樣。但區別是存在的，而且很大。
所以，對於預算不那麼緊張，最好還是多投入點盡量越快越好，可用性（7*24）越高越好
對於資料庫，在很多情況下，dba（這裡指不僅僅是做簡單運維的角色）和coder（甚至coder公升級的架構師，比較缺乏對db的深入理解）的想法、思維區別都是很大的。就像一把菜刀，大媽大嬸看到的就是切菜工具，但若是別有用心之徒看到的就是作案工具，但若是警察看到的就會是要預防點什麼。。。作為最大眾的應用開發者，在資料庫上建表寫**完成功能，萬事大吉，而且在boss面前價值也就體現出來了。當資料量、併發量增大時，會感覺到扛不住了，天靈靈，地靈靈，但效率卻不靈。。。這時dba角色該出場了。順著前文的邏輯修整，稱為優化。也就是將需求（既定的任務）按最有效率的方式去達成。
另外，還有較多的誤區，作為資料庫平台，提供了很多特性，但是，很多特性也不一定符合很多生產場景，比如負載均衡。在sql server 2012及以後，有alwayson，是不是就是理想中的均衡效能呢。。。還不是。對於實時資料與潛在的延遲資料，需要對應用規劃、設計作調整，才能良好適應業務需求。單從概念上來說，資料能實時同步是個很完美的概念，但是從平衡效能的響應時間來說，實時同步會影響主伺服器對客戶端的響應的。所以，不能把概念當理想，當現實。
關於PHP商城系統效能優化
最近在研究 系統原始碼，在想怎麼去更好的優化，一般來說，效能優化可先從大的方向開始考慮，從對影響效能比較大的因素來考慮，比如現在使用php5.7，效能可以成倍提高，這些都是客觀因素，類似現在網上的開源 類似dsmall開源 系統這類，基本都能支援高版本php，最後考慮的應該是php語法細節上。php...
ulimit關於系統連線數的優化
linux 預設值 open files 和 max user processes 為 1024 ulimit n 1024 ulimit u 1024 問題描述 說明 server 只允許同時開啟 1024 個檔案，處理 1024 個使用者程序 使用ulimit a 可以檢視當前系統的所有限制值，...
關於tableview優化
uitableviewcell tableview uitableview tableview cellforrowatindexpath nsindexpath indexpath 這個 方法的實現，在可見的頁面是會重複繪製頁面的，所以絕大部分人都會在這裡做一些 處理 比如 static nsst...