php性能優化方法

㈠ php開發中如何提高系統的穩定性和可靠性

PHP 應用的高性優化，很多時候我們把業務代碼做一些優化，反而是簡單又高效的。

• 業務的非同步解耦，比如，我們把耗時的多個分表數據的排行榜，通過其他服務做分布統計，然後再綜合，最終輸出到redis list中，那我們前端 PHP 在調用數據的時候，就不用實時計算了。

• 緩存的多級處理，業務復雜以後，經常看到一份相同的數據讀取 N 次，盡管是有緩存伺服器，但是讀取的時候也會有網路 I/O 的開銷，考慮到我們 PHP 一般使用場景下都是單進程，使用頻率高的，則應該優先使用進程內緩存。然後再本地緩存，然後再到網路緩存。

• 單例的運用，不要小看了對象的構造，很多時候我們在同一進程中，會發現同時構造了 N 多相同的對象。每一次的初始化都是一塊內存的開辟和 CPU 的消耗。

高性能，一個就是運行環境的優化，另一個是代碼本身的優化。

運行環境的優化，覆蓋面也很廣，包括系統層面的內核，文件系統類型，資料庫及緩存服務本身的性能優化，再到PHP解釋器的性能優化等等，PHP不同運行方式的差異（比如Apache模塊，還有PHP-FPM等等）。

代碼優化方面，我覺得可維護性和代碼可讀性的重要性大於高性能。代碼優化可以藉助profiling工具來分析，找到真實訪問條件下，處理瓶頸在哪裡，再去做針對性的優化。當然自己在初次設計和實現的時候，就需要做一定的整體考慮，例如怎麼設計能夠減少資料庫的查詢次數，如何減少重復的操作，了解同一問題的多種解決辦法哪一種效率更高（包括演算法上的差異，以及PHP的不同方式導致的差異等等），如何設計緩存來提高緩存命中率等等。有一些設計需要在體驗和效率上做個權衡。

保證穩定性，同樣也分運行環境和代碼本身。前者要對線上服務做完整的監控，這個有很多完善和強大的開源工具可以使用，保障基礎環境是穩定可控的，並且能夠及時發現問題，進行修復。至於代碼，除了盡量做完整的測試，開發的時候就需要考慮可能的問題。另外針對PHP，開發環境可以把error_reporting完全打開。還有需要知道常見的安全問題（XSS，SQL注入，CSRF，越權等），畢竟安全問題也是穩定的一部分。

㈡ php+mysql 如何優化千萬級數據模糊查詢加快

關於mysql處理百萬級以上的數據時如何提高其查詢速度的方法

最近一段時間由於工作需要，開始關注針對Mysql資料庫的select查詢語句的相關優化方法。

由於在參與的實際項目中發現當mysql表的數據量達到百萬級時，普通SQL查詢效率呈直線下降，而且如果where中的查詢條件較多時，其查詢速度簡直無法容忍。曾經測試對一個包含400多萬條記錄（有索引）的表執行一條條件查詢，其查詢時間竟然高達40幾秒，相信這么高的查詢延時，任何用戶都會抓狂。因此如何提高sql語句查詢效率，顯得十分重要。以下是網上流傳比較廣泛的30種SQL查詢語句優化方法：
1、應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。

2、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

3、應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0

4、盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20

5、下面的查詢也將導致全表掃描：(不能前置百分號)
select id from t where name like 『%c%』
若要提高效率，可以考慮全文檢索。

6、in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3

7、如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然 而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num

8、應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2

9、應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)=』abc』–name以abc開頭的id
select id from t where datediff(day,createdate,』2005-11-30′)=0–』2005-11-30′生成的id
應改為:
select id from t where name like 『abc%』
select id from t where createdate>=』2005-11-30′ and createdate<』2005-12-1′

10、不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

11、在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使 用，並且應盡可能的讓欄位順序與索引順序相一致。

12、不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(…)

13、很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)

14、並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位 sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。

15、索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。

16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。

17、盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會 逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

18、盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。

19、任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。

20、盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。

21、避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。

22、臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使 用導出表。

23、在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。

24、如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。

25、盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。

26、使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。

27、與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時 間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。

28、在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。

29、盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

30、盡量避免大事務操作，提高系統並發能力。

㈢ 升級php7.3 linux伺服器cpu 突然很高

1、通過寶塔面板安裝的建站環境是LNMP，使用的Nginx 1.16.1、MySQL 5.5.62、PHP-7.0。2、優化PHP7.0設置。先進入到PHP7.0管理頁面。首先先安裝一個opcache緩沖器，用於加速PHP腳本，其他的就都按默認的來吧，畢竟安裝的擴展太多容易影響性能。修改max_execution_time時間為20.性能調整。這里可以根據自己伺服器配置進行設置，寶塔面板比較人性化，會根據你的伺服器配置設置推薦方案。可以根據自己伺服器內存大小進行計算，一般一個php-fpm進程佔用內存30M左右，以1024MB內存1G內存）來計算，大概可以設置34個並發。使用的就是1核1G內存配置的伺服器，安裝寶塔面板後推薦的是40並發，用不到那麼高的並發，所以設置了20並發的方案，並把max_spare_servers數字調整成了14。

㈣ 如何對低硬體配置的中小型php網站進行性能優化

本人對php不熟悉，現在採用PHP的magento開源項目來做，在盡量少代碼修改的情況下讓頁面載入快些（期望日IP少於2,000，PV少於50,000，首頁打開3s以內）。網站是運行在Digital ocean的VPS（1GB 內存，30GB SSD硬碟）上的，不能做負載均衡。
這個站的圖片比較多，也比較大，但總體數據量在10GB以下。在chrome下監控了打開速度，發現首頁文件等待時間達到了5s，而接收時間為幾百毫秒。另外一些靜態文件（JS，CSS很大，並且都在head內）也block住了其他頁面元素的下載和頁面渲染。所以需要對頁面和伺服器同時進行優化。
我的想法是從以下幾個方面來做：
1.首先從架構上使用lanmp（偏向這個）或者lamp。
打算使用網上的一鍵安裝包，不太清楚這幾個之間最佳的版本組合是什麼樣的（都用最新版本？）? 是自己單獨編譯還是一鍵安裝好？
2.服務端優化，主要使用緩存手段
1）Zend Optimizer優化PHP
2）APC、eaccelerator或者XCache對PHP緩存以及最新出來的Opcache。哪個比較好？
3）Varnish配合Nginx進行緩存靜態資源緩存。相對於squid，哪個比較好？
4）memcached進行資料庫緩存
1-4項同時使用不知道會不會有沒有沖突？或者有沒有更好的方案。因為不想對代碼進行大改，所以服務端緩存最佳實踐這塊請重點給出意見。
3. 使用CDN加速靜態資源
4. 優化靜態資源，使用minify來合並壓縮CSS,JS這些靜態資源
5. 啟用gzip
6. 對圖片和JS等靜態資源增加Expires頭，這條應該算頁面優化吧，放到後面來。
參考了一些資料後發現優化方法有很多，用的太多方法（特別是緩存手段）隱患越大，有沒有優化的最佳策略或者方法論（而不僅僅從工具上）？

㈤ php有哪些優化技巧

優化的點有很多，看具體使用環境：

1、 用單引號代替雙引號來包含字元串，這樣做會更快一些。因為 PHP 會在雙引號包圍的 字元串中搜尋變數，單引號則不會，注意：只有 echo 能這么做，它是一種可以把多個字元 串當作參數的「函數」(譯註：PHP 手冊中說 echo 是語言結構，不是真正的函數，故把函數 加上了雙引號)。

2、如果能將類的方法定義成 static，就盡量定義成 static，它的速度會提升將近 4 倍。

3、$row['id'] 的速度是$row[id]的 7 倍。

4、echo 比 print 快，並且使用 echo 的多重參數(譯註：指用逗號而不是句點)代替字元串 連接，比如 echo $str1,$str2。

5、在執行 for 循環之前確定最大循環數，不要每循環一次都計算最大值，最好運用 foreach 代替。

6、注銷那些不用的變數尤其是大數組，以便釋放內存。

7、盡量避免使用__get，__set，__autoload。

8、require_once()代價昂貴。

9、include 文件時盡量使用絕對路徑，因為它避免了 PHP 去 include_path 里查找文件的速 度，解析操作系統路徑所需的時間會更少。

10、如果你想知道腳本開始執行(譯註：即伺服器端收到客戶端請求)的時刻，使用 $_SERVER['REQUEST_TIME'] 要好於 time()

11、函數代替正則表達式完成相同功能。

12、str_replace 函數比 preg_replace 函數快，但 strtr 函數的效率是 str_replace 函數的四倍。

13、如果一個字元串替換函數，可接受數組或字元作為參數，並且參數長度不太長，那麼 可以考慮額外寫一段替換代碼， 使得每次傳遞參數是一個字元， 而不是只寫一行代碼接受數 組作為查詢和替換的參數。

14、使用選擇分支語句(譯註：即 switch case)好於使用多個 if，else if 語句。

15、用@屏蔽錯誤消息的做法非常低效，極其低效。

16、打開 apache 的 mod_deflate 模塊，可以提高網頁的瀏覽速度。

17、資料庫連接當使用完畢時應關掉，不要用長連接。

18、錯誤消息代價昂貴。

19、在方法中遞增局部變數，速度是最快的。幾乎與在函數中調用局部變數的速度相當。

20、遞增一個全局變數要比遞增一個局部變數慢 2 倍。

21、遞增一個對象屬性(如：$this->prop++)要比遞增一個局部變數慢 3 倍。

22、遞增一個未預定義的局部變數要比遞增一個預定義的局部變數慢 9 至 10 倍。

23、僅定義一個局部變數而沒在函數中調用它，同樣會減慢速度(其程度相當於遞增一個局 部變數)。PHP 大概會檢查看是否存在全局變數。

24、方法調用看來與類中定義的方法的數量無關，因為我(在測試方法之前和之後都)添加了 10 個方法，但性能上沒有變化。

25、派生類中的方法運行起來要快於在基類中定義的同樣的方法。

26、調用帶有一個參數的空函數，其花費的時間相當於執行 7 至 8 次的局部變數遞增操作。 類似的方法調用所花費的時間接近於 15 次的局部變數遞增操作。

27、Apache 解析一個 PHP 腳本的時間要比解析一個靜態 HTML 頁面慢 2 至 10 倍。盡量 多用靜態 HTML 頁面，少用腳本。

28、除非腳本可以緩存，否則每次調用時都會重新編譯一次。引入一套 PHP 緩存機制通常 可以提升 25%至 100%的性能，以免除編譯開銷。

29、盡量做緩存，可使用 memcached。memcached 是一款高性能的內存對象緩存系統， 可用來加速動態 Web 應用程序，減輕資料庫負載。對運算碼 (OP code)的緩存很有用，使 得腳本不必為每個請求做重新編譯。

30、 當操作字元串並需要檢驗其長度是否滿足某種要求時， 你想當然地會使用 strlen()函數。 此函數執行起來相當快，因為它不做任何計算，只返回在 zval 結構(C 的內置數據結構，用 於存儲 PHP 變數)中存儲的已知字元串長度。但是，由於 strlen()是函數，多多少少會有些 慢，因為函數調用會經過諸多步驟，如字母小寫化(譯註：指函數名小寫化，PHP 不區分函 數名大小寫)、哈希查找，會跟隨被調用的函數一起執行。在某些情況下，你可以使用 isset() 技巧加速執行你的代碼。 (舉例如下) if (strlen($foo) < 5) { echo 「Foo is too short」$$ } (與下面的技巧做比較) if (!isset($foo{5})) { echo 「Foo is too short」$$ } 調用 isset()恰巧比 strlen()快，因為與後者不同的是，isset()作為一種語言結構，意味著它 的執行不需要函數查找和字母小寫化。 也就是說， 實際上在檢驗字元串長度的頂層代碼中你 沒有花太多開銷。

31、當執行變數$i 的遞增或遞減時，$i++會比++$i 慢一些。這種差異是 PHP 特有的，並不 適用於其他語言， 所以請不要修改你的 C 或 Java 代碼並指望它們能立即變快， 沒用的。 ++$i 更快是因為它只需要 3 條指令(opcodes)，$i++則需要 4 條指令。後置遞增實際上會產生一 個臨時變數，這個臨時變數隨後被遞增。而前置遞增直接在原值上遞增。這是最優化處理的 一種，正如 Zend 的 PHP 優化器所作的那樣。牢記這個優化處理不失為一個好主意，因為 並不是所有的指令優化器都會做同樣的優化處理， 並且存在大量沒有裝配指令優化器的互聯 網服務提供商(ISPs)和伺服器。

32、並不是事必面向對象(OOP)，面向對象往往開銷很大，每個方法和對象調用都會消耗很 多內存。

33、並非要用類實現所有的數據結構，數組也很有用。

34、不要把方法細分得過多，仔細想想你真正打算重用的是哪些代碼?

35、當你需要時，你總能把代碼分解成方法。

36、盡量採用大量的 PHP 內置函數。

37、如果在代碼中存在大量耗時的函數，你可以考慮用 C 擴展的方式實現它們。

38、 評估檢驗(profile)你的代碼。 檢驗器會告訴你， 代碼的哪些部分消耗了多少時間。 Xdebug 調試器包含了檢驗程序，評估檢驗總體上可以顯示出代碼的瓶頸。

39、mod_zip 可作為 Apache 模塊，用來即時壓縮你的數據，並可讓數據傳輸量降低 80%。

40、在可以用 file_get_contents 替代 file、fopen、feof、fgets 等系列方法的情況下，盡量 用 file_get_contents，因為他的效率高得多!但是要注意 file_get_contents 在打開一個 URL 文件時候的 PHP 版本問題;

41、盡量的少進行文件操作，雖然 PHP 的文件操作效率也不低的;

42、優化 Select SQL 語句，在可能的情況下盡量少的進行 Insert、Update 操作(在 update 上，我被惡批過);

43、盡可能的使用 PHP 內部函數(但是我卻為了找個 PHP 裡面不存在的函數，浪費了本可 以寫出一個自定義函數的時間，經驗問題啊!);

44、 循環內部不要聲明變數， 尤其是大變數： 對象(這好像不只是 PHP 裡面要注意的問題吧?);

45、多維數組盡量不要循環嵌套賦值;

46、在可以用 PHP 內部字元串操作函數的情況下，不要用正則表達式;

47、foreach 效率更高，盡量用 foreach 代替 while 和 for 循環;

48、用單引號替代雙引號引用字元串;

49、「用 i+=1 代替 i=i+1。符合 c/c++的習慣，效率還高」

50、對 global 變數，應該用完就 unset()掉;