作為乙個行走江湖多年的老中醫，今天受命去解決一例前端頁面展現緩慢的問題。問題頁的情況如下：
apache + php
使用smarty模板輸出內容
頁面最終輸出內容較大，80k+
頁面執行時間在500ms以上
祭出法寶xhprof對問題頁面做了細緻檢查，發現頁面的瓶頸竟然是模板(編譯後的)中的乙個echo語句，這個echo語句輸出的字串比較大，大概是50k+位元組，花費時間為400多毫秒，佔整個頁面執行時間的80%。這樣的echo輸出在站點首頁中其實是很常見的事情，沒有資料庫操作，按道理執行時間不應該這麼長。
於是猛力使用搜尋技能，最終在php手冊的echo部分找到了一些蛛絲馬跡，早在2023年就有前輩認為通過echo輸出大字串到客戶端會引起伺服器的效能問題，據我測試，在這個場景下使用print其實也是一樣的慢。建議的解決辦法是把字串切割成更小的字串輸出，展現速度會有提公升，輸出函式如下：
<?php
function echobig($string, $buffersize = 8192)
?>
但是上面的處方不太對症，整個echobig的輸出時間仍然在400毫秒左右，沒有太大改善。
考慮到是輸出大量內容到客戶端比較慢，於是檢查了apache的配置，原來還沒開啟deflate進行壓縮，遂啟用之。再次使用xhprof進行檢查，這條echo的輸出時間降低到5ms左右。
400ms到5ms，乙個配置問題會產生80倍的差距，還真是省老錢了。這個故事告訴我們，壓縮輸出真的很重要。
為什麼count 這麼慢？
當我們查詢一張資料量很大的表時，使用sql select count from t1 這條sql非常耗時。那麼當執行count 的時候發生了什麼呢？count 1 的sql執行計畫如下 count 的sql執行計畫如下 兩者執行計畫相同，所以速度相同。首先初始化時，執行一次精確的計數 select ...
為什麼count 這麼慢
不同count的用法 count 是乙個聚合函式，對於返回的結果集，一行行地判斷，如果count函式的引數不是null，累計值就加1，否則不加。最後返回累計值。count的用法有多種，分別是count count 字段 count 1 count 主鍵id 那麼多種用法，到底有什麼差別呢？當然，前提...
為什麼我的並查集這麼慢！！！
在我剛開始使用並查集這種演算法的時候，我一直搞不明白為什麼別人總是說這種演算法很好，在做題的時候會經常用到。但是我自己用起來的時候時間總是會超，一直很納悶。今天重新做到一道別人都是使用並查集來解決的題目時，我才發現了我一直以來的錯誤！是真蠢呀！寫這篇部落格來吐槽一下自己，順便給自己留下乙個更深刻的印...