㈠ php 分頁查詢怎麼redis緩存
對於有分頁條件的緩存，我們也可以按照不同的分頁條件來緩存多個key，比如分頁查詢產品列表,page=1&limit=10和page=1&limit=5這兩次請求可以這樣緩存查詢結果
proctList:page:1:limit:10
proctList:page:1:limit:5
這個是一種常見方案，但是存在著一些問題：
緩存的value存在冗餘，proctList:page:1:limit:10緩存的內容其實是包括了proctList:page:1:limit:5中的內容（緩存兩個key的時候，數據未發生變化的情況下）
僅僅是改變了查詢條件的分頁條件，就會導致緩存未命中，降低了緩存的命中率
為了保證數據一致性，需要清理緩存的時候，很難處理，redis的keys命令對性能影響很大，會導致redis很大的延遲，生產環境一般來說禁止該命令。自己手動拼緩存key，你可能根本不知道拼到哪一個page為止。
放棄數據一致性，通過設置失效時間來自動失效，可能會出現查詢第一頁命中了緩存，查詢第二頁的時候未命中緩存，但此時數據已經發生了改變，導致第二頁查詢返回的和第一頁相同的結果。
以上，在分頁條件下這樣使用常規方案總感覺有諸多困擾，諸多麻煩，那是不是就應該放棄使用緩存？
基於SortedSet的分頁查詢緩存方案
首先想到的解決方法是使用@see ListOperations<K, V>不再根據分頁條件使用多個key，而是使用一個key，也不分頁將全部的數據緩存到redis中，然後按照分頁條件使用range(key,start,limit)獲取分頁的結果，這個會導致一個問題，當緩存失效時，並發的寫緩存會導致出現重復數據
所以想到通過使用set來處理並發時的重復數據，@see ZSetOperations<K, V>
代碼邏輯如下：
range(key,start,limit)按照分頁條件獲取緩存，命中則直接返回
緩存未命中，查詢（沒有分頁條件）資料庫或是調用（沒有分頁）底層介面
add(key,valueScoreMap<value,score>)寫入緩存，expire設置緩存時間
當需要清理緩存時，直接刪除key，如果是因為數據新增和刪除，可以add(key,value,score)或remove(key,value)
redis中會按照score分值升序排列map中的數據，一般的，score分值是sql語句的order by filedA的filedA的值，這樣能保證數據一致性
但是這種方式也存在一定問題：
這個key緩存的value確實是熱數據，但可能只有少數數據被頻繁使用其餘的可能根本就未被使用，比如數據有100頁，實際可能只會用到前10頁，這也會導致緩存空間的浪費，如果使用了redis虛擬內存，也會有一定影響
sql查詢由原來的分頁查詢變成了不分頁查詢，緩存失效後，系統的處理能力較之前會有下降，尤其是對於大表.
㈡ php緩存類文件分頁，自定義文件名
在類里加一個setcacheid函數
public function setcacheid($cacheid)
{
$this->cacheid = $cacheid;
}
用這個類，不如下載一個精簡版的smarty 或者比ecshop里提取那個類使用，功能更完美！
㈢ PHP+MySQL高效的分頁方法,如何優化LIMIT,OFFSET進行的分頁
很多應用往往只展示最新或最熱門的幾條記錄，但為了舊記錄仍然可訪問，所以就需要個分頁的導航欄。然而，如何通過MySQL更好的實現分頁，始終是比較令人頭疼的問題。雖然沒有拿來就能用的解決辦法，但了解資料庫的底層或多或少有助於優化分頁查詢。
我們先從一個常用但性能很差的查詢來看一看。
SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15
這個查詢耗時0.00sec。So，這個查詢有什麼問題呢？實際上，這個查詢語句和參數都沒有問題，因為它用到了下面表的主鍵，而且只讀取15條記錄。
CREATE TABLE city (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
city varchar(128) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;
真正的問題在於offset(分頁偏移量)很大的時候，像下面這樣：
SELECT *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
上面的查詢在有2M行記錄時需要0.22sec，通過EXPLAIN查看SQL的執行計劃可以發現該SQL檢索了100015行，但最後只需要15行。大的分頁偏移量會增加使用的數據，MySQL會將大量最終不會使用的數據載入到內存中。就算我們假設大部分網站的用戶只訪問前幾頁數據，但少量的大的分頁偏移量的請求也會對整個系統造成危害。Facebook意識到了這一點，但Facebook並沒有為了每秒可以處理更多的請求而去優化資料庫，而是將重心放在將請求響應時間的方差變小。
對於分頁請求，還有一個信息也很重要，就是總共的記錄數。我們可以通過下面的查詢很容易的獲取總的記錄數。
SELECT COUNT(*)
FROM city;
然而，上面的SQL在採用InnoDB為存儲引擎時需要耗費9.28sec。一個不正確的優化是採用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁查詢時事先准備好符合條件的記錄數，隨後只要執行一句 select FOUND_ROWS(); 就能獲得總記錄數。但是在大多數情況下，查詢語句簡短並不意味著性能的提高。不幸的是，這種分頁查詢方式在許多主流框架中都有用到，下面看看這個語句的查詢性能。
SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
這個語句耗時20.02sec，是上一個的兩倍。事實證明使用 SQL_CALC_FOUND_ROWS 做分頁是很糟糕的想法。
下面來看看到底如何優化。文章分為兩部分，第一部分是如何獲取記錄的總數目，第二部分是獲取真正的記錄。
高效的計算行數
如果採用的引擎是MyISAM，可以直接執行COUNT(*)去獲取行數即可。相似的，在堆表中也會將行數存儲到表的元信息中。但如果引擎是InnoDB情況就會復雜一些，因為InnoDB不保存表的具體行數。
我們可以將行數緩存起來，然後可以通過一個守護進程定期更新或者用戶的某些操作導致緩存失效時，執行下面的語句：
SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);
獲取記錄
下面進入這篇文章最重要的部分，獲取分頁要展示的記錄。上面已經說過了，大的偏移量會影響性能，所以我們要重寫查詢語句。為了演示，我們創建一個新的表「news」，按照時事性排序(最新發布的在最前面)，實現一個高性能的分頁。為了簡單，我們就假設最新發布的新聞的Id也是最大的。
CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;
一個比較高效的方式是基於用戶展示的最後一個新聞Id。查詢下一頁的語句如下，需要傳入當前頁面展示的最後一個Id。
SELECT *
FROM news WHERE id < $last_id
ORDER BY id DESC
LIMIT $perpage
查詢上一頁的語句類似，只不過需要傳入當前頁的第一個Id，並且要逆序。
SELECT *
FROM news WHERE id > $last_id
ORDER BY id ASC
LIMIT $perpage
上面的查詢方式適合實現簡易的分頁，即不顯示具體的頁數導航，只顯示「上一頁」和「下一頁」，例如博客中頁腳顯示「上一頁」，「下一頁」的按鈕。但如果要實現真正的頁面導航還是很難的,下面看看另一種方式。
SELECT id
FROM (
SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt
FROM news
JOIN (SELECT @cnt:= 0)T
WHERE id < $last_id
ORDER BY id DESC
LIMIT $perpage * $buttons
)C
WHERE cnt = 0;
通過上面的語句可以為每一個分頁的按鈕計算出一個offset對應的id。這種方法還有一個好處。假設，網站上正在發布一片新的文章，那麼所有文章的位置都會往後移一位，所以如果用戶在發布文章時換頁，那麼他會看見一篇文章兩次。如果固定了每個按鈕的offset Id，這個問題就迎刃而解了。Mark Callaghan發表過一篇類似的博客，利用了組合索引和兩個位置變數，但是基本思想是一致的。
如果表中的記錄很少被刪除、修改，還可以將記錄對應的頁碼存儲到表中，並在該列上創建合適的索引。採用這種方式，當新增一個記錄的時候，需要執行下面的查詢重新生成對應的頁號。
SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;
當然，也可以新增一個專用於分頁的表，可以用個後台程序來維護。
UPDATE pagination T
JOIN (
SELECT id, CEIL((p:= p + 1) / $perpage) page
FROM news
ORDER BY id
)C
ON C.id = T.id
SET T.page = C.page;
現在想獲取任意一頁的元素就很簡單了：
SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;
還有另外一種與上種方法比較相似的方法來做分頁，這種方式比較試用於數據集相對小，並且沒有可用的索引的情況下—比如處理搜索結果時。在一個普通的伺服器上執行下面的查詢，當有2M條記錄時，要耗費2sec左右。這種方式比較簡單，創建一個用來存儲所有Id的臨時表即可(這也是最耗費性能的地方)。
CREATE TEMPORARY TABLE _tmp (KEY SORT(random))
SELECT id, FLOOR(RAND() * 0x8000000) random
FROM city;
ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;
接下來就可以向下面一樣執行分頁查詢了。
SELECT *
FROM _tmp
WHERE OFFSET >= $offset
ORDER BY OFFSET
LIMIT $perpage;
簡單來說，對於分頁的優化就是。。。避免數據量大時掃描過多的記錄。
㈣ PHP DUXCMS如何開啟頁面緩存
1.頁面緩存。頁面緩存指之前載入過的頁面以文件方式緩存在伺服器中，在一段時間內再次載入相同頁面時無需重新執行頁面邏輯直接載入靜態頁面。rubyPHP的頁面緩存是自動進行的，在config/tpl.php中可配置是否啟用緩存以及緩存文件的有效期。當然這僅僅是全局設置，在調用視圖時可重新指定是否啟用緩存以及緩存有效期。
2.SQL緩存。sql緩存指之前執行過的查詢sql語句以及他的結果緩存在內存中，在一段時間內用相同的sql語句執行查詢操作時不經過資料庫直接返回內存中數據。rubyPHP使用Redis以鍵值方式緩存sql語句以及他的對應結果。rubyPHP能夠在php7上完美運行。（附：關於windows php7 redis 擴展的下載參照我的另一篇博客：http://blog.csdn.net/fanghailiang2016/article/details/51396649）。rubyPHP重寫了mysql_query以及mongo_query方法，在執行查詢sql查詢語句時會優先載入未過期的緩存數據。與頁面緩存類似，sql緩存的全局配置路徑為config/redis.php，在具體執行sql語句前可重新執行是否使用緩存以及緩存有效期。
3.讀寫分離。讀寫分離是建立在主從同步基礎上為了減輕伺服器壓力，將查詢語句轉移到從伺服器上執行的解決方案。rubyPHP重寫了mysql_query，mongo_query函數，除了對查詢語句進行內存級緩存的優化，同時也將查詢語句放到了從伺服器上執行。mysql的主從配置文件路徑為config/mysql.php。
4.html壓縮。html壓縮配合頁面緩存，前者降低了伺服器端壓力，後者減少了輸出內容所佔空間，將html文件中的空格換行等進行壓縮，減少了輸出文件的大小，在一定程度上保護了html的安全。
rubyPHP在代碼結構上模仿CI，在功能上模仿thinkPHP。
rubyPHP的功能包含以下幾方面：
1.使用了thinkPHP的M方法操作資料庫。對於一些簡單的sql語句無需手工寫，用熟悉的M()->where()->limit()->find()這樣的語法即可完成。曾經面試有人問我為什麼thinkPHP的M方法能夠進行連續操作，現在終於明白是使用了單利模式。
2.屏蔽了資料庫的差異。M方法的另一個優點是用來組件sql語句，對高層屏蔽資料庫差異。當然，對於復雜的查詢，M方法是做不到的，此時可以使用已被重寫過的mysql_query以及mongo_query執行你的sql語句。
3.自定義路由。這一點模仿了CI的route.php，將url同控制器的映射關系寫到一個配置文件里。
不足之處：
view文件不支持變數循環輸出。目前的解決方案是使用angularjs調用介面在頁面輸出內容。框架示常式序便是一個使用angularjs的和bootstrap的界面。
㈤ thinkphp框架，數據動態緩存後，讀取緩存數據時分頁怎麼辦
不確定正確性，但是確實可行，讀取緩存後賦值到數組，通過array_slice函數處理，如：
$blog = S('blogname'); //賦值
$count = count($blog); //條數統計
$page = new Page($count,12); //實例化page類
$this -> Blog = array_slice($blog,$page->firstRow,$page->listRows); //分配到模板
$this -> page = $page -> show();
$this -> display();
㈥ php怎麼使用緩存
假設要訪問add_friend.php,先查看緩存目錄下（假設為cache文件夾）下有沒有與add_friend.php對應的緩存文件(文件類型一般為php)，若無則重新生成，若有，且緩存時間沒有過期則直接調用該緩存文件既可以，如果過期則重新生成
生成緩存文件則主要是採用正則替換的方式
㈦ php 中如何使用緩存，使用哪種緩存機制最好;
php的緩存三種.有文件緩存，資料庫緩存，memcache緩存;
memcache緩存要求對伺服器支持，而且它的緩存是由期限的，一般是30天。這種緩存的效率是最高的。讀存取的速度最快。
資料庫緩存
和
文件緩存比較簡單。適用小的項目。和php新手
㈧ php緩存類文件分頁，應該怎麼添加，請直接給文件
PDF是電子文檔格式，主要是用來瀏覽，如果要添加，就需要用編輯軟體，編輯軟體有很多，不過我比較熟悉的是FREEHAND，普通的也有，比如pagemaker,WORD也是可以的，如果是一個PDF文件，你需要轉換出格式才能編輯的。
㈨ php 數據緩存
一種是對 頁面結果的緩存 應用伺服器級別的 軟體如 squid
一種是 內存級別的 一般是對 php 頻繁調用的並且如果每次查詢會消耗大量資源的數據 軟體有 memcached
一種是 對php 程序進行優化編碼的緩存 如 apache 裡面的 apc, eAccelerator, XCache 等
還有一種就是文件緩存 這種一般是 用php自己實現的 沒什麼可說的.
看你的具體需求是怎樣的了..有疑問 請聯系 1465663870
㈩ php 緩存怎麼寫
PHP數據緩存常用頁面緩存 靜態緩存
php頁面緩存主要用到的是ob系列函數，如ob_start(),ob_end_flush(),ob_get_contents()
靜態緩存是指靜態化，直接生成HTML或XML等文本文件，有更新的時候重生成一次，適合於不太變化的頁面
給你個頁面緩存的例子
function page_cache($ttl = 0)
{
$ttl = $ttl ? $ttl : PAGE_TTL;//緩存時間，默認3600s
$contents = ob_get_contents();//從緩存中獲取內容
$contents = "<!--page_ttl:".(time() + $ttl)."-->n".$contents;
//加上自定義頭部：過期時間=生成時間+緩存時間
file_put_contents(PAGE_FILE, $contents);//寫入緩存文件中
ob_end_flush();//釋放緩存
}