O'Reilly Learning PHP MySQL 第二版
專注于為中小企業(yè)提供成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)華池免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了近1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
;ID=170283
PHP 5 傻瓜書
;ID=156854
PHP官方參考手冊 中文+英文CHM版
;ID=174312
Upgrading to PHP 5
;ID=172787
Wrox Beginning PHP 5
;ID=146843
PHP 5 Advanced
;ID=152684
PHP 5與MySQL編程初學(xué)者指南
;ID=152044
PHP 5和MySQL 5 從入門到精通 PDF文字版
;ID=166059
PHP 4.1 從入門到精通
;ID=159334
O'Reilly PHP Cookbook 第二版
How to Do Everything with PHP and MySQL
;ID=175991
PHP MySQL Web Development
;ID=175913
PHP Programming Solutions
;ID=173163
PHP Objects Patterns and Practice
;ID=173160
Learning PHP Data Objects
;ID=173151
PHP技術(shù)內(nèi)幕
;ID=159332
PHP最新參考手冊
;ID=146233
PHP程序設(shè)計(jì)
;ID=146171
PHP經(jīng)典100例
;ID=152400
PHP by Example
;ID=176304
Object Oriented PHP Concepts Techniques and Code
;ID=152398
The PHP Anthology 第二版
;ID=167353
PHP API使用完全指南
;ID=164843
Wiley出版 Makeing Use of PHP
;ID=166790
PHP實(shí)例教程
;ID=152574
PHP in Action
;ID=152648
PHP+MySQL網(wǎng)絡(luò)開發(fā)技術(shù)
;ID=156149
PHP設(shè)計(jì)模式構(gòu)架師指南
Dreamweaver CS3 with CSS, Ajax, and PHP
;ID=147123
AJAX and PHP Building Responsive Web Applications
;ID=151261
Beginning Ajax with PHP
;ID=146176
PHP Programming with PEAR
;ID=148389
PHP MySQL and Apache自學(xué)教程
;ID=146232
PHP Apache和MySQL網(wǎng)頁開發(fā)初步
;ID=148871
24小時學(xué)會使用PHP MySQL Apache
;ID=149004
PHP MySQL 網(wǎng)絡(luò)應(yīng)用程序開發(fā)核心
;ID=149005
Professional LAMP - Linux,Apache,MySQL and PHP 5 Web Development
;ID=152045
Setting Up LAMP - Getting Linux Apache MySQL and PHP Working Together
;ID=157654
Beginning PHP,Apache,MySQL Web Developmnet
;ID=151985
Beginning PHP and Oracle 從入門到精通
PHP Data Objects for MySQL
;ID=152186
MySQL and PHP from Scratch
;ID=152162
Extending and Embedding PHP
;ID=152160
Wiley出版 Secure PHP Development
;ID=165544
O'Reilly Building Tag Clouds in Perl and PHP
;ID=152158
Wrox Professional Apache Tomcat 5
;ID=152054
PHP MySQL編程初學(xué)者指南
;ID=158793
Beginning PHP and Oracle (PDF文字版)
;ID=159155
Advanced PHP for Web Professionals
;ID=159168
Essential PHP Security
;ID=175045
Pro PHP XML and Web Services
Apache Server 2.0 實(shí)用指南
;ID=159297
Apache管理員手冊
;ID=159296
Apache使用指南與實(shí)現(xiàn)原理
;ID=159287
PHP專業(yè)項(xiàng)目實(shí)例開發(fā) 中文PDF版
;ID=159322
PHP高級開發(fā)技術(shù)與實(shí)例 中文PDF影版
;ID=159319
PHP 5 for Flash
;ID=159407
O'Reilly - Tomcat權(quán)威指南
;ID=160138
Wrox Professional Apache Tomcat 6
;ID=157418
Pro Jakarta Tomcat 5
;ID=160230
Foundations of PEAR - Rapid PHP Development
;ID=160612
Practical Web 2.0 Applications with PHP(Apress 2008最新版)
;ID=170237
Practical Apache Struts 2 Web 2.0 Projects
;ID=170311
記得我還在念大學(xué)的時候，一位教我們單片機(jī)的老師說了一句話："學(xué)習(xí)編程剛開始你就得照葫蘆畫瓢...",以前我在mysql中分頁都是用的 limit 100000,20這樣的方式，我相信你也是吧，但是要提高效率，讓分頁的代碼效率更高一些，更快一些,那我們又該怎么做呢?
第一部分：看一下分頁的基本原理：
第一部分：看一下分頁的基本原理：
mysql explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec) 對上面的mysql語句說明：limit 10000,20的意思掃描滿足條件的10020行，扔掉前面的10000行，返回最后的20行，問題就在這里，如果是limit 100000,100，需要掃描100100行，在一個高并發(fā)的應(yīng)用里，每次查詢需要掃描超過10W行，性能肯定大打折扣。文中還提到limit n性能是沒問題的，因?yàn)橹粧呙鑞行。
第二部分：根據(jù)雅虎的幾位工程師帶來了一篇Efficient Pagination Using MySQL的報(bào)告內(nèi)容擴(kuò)展：在文中提到一種clue的做法，給翻頁提供一些線索，比如還是SELECT * FROM message ORDER BY id DESC，按id降序分頁，每頁20條，當(dāng)前是第10頁，當(dāng)前頁條目id最大的是1020，最小的是1000，如果我們只提供上一頁、下一頁這樣的跳轉(zhuǎn)（不提供到第N頁的跳轉(zhuǎn)），那么在處理上一頁的時候SQL語句可以是：
完整請到：
很多應(yīng)用往往只展示最新或最熱門的幾條記錄，但為了舊記錄仍然可訪問，所以就需要個分頁的導(dǎo)航欄。然而，如何通過MySQL更好的實(shí)現(xiàn)分頁，始終是比較令人頭疼的問題。雖然沒有拿來就能用的解決辦法，但了解數(shù)據(jù)庫的底層或多或少有助于優(yōu)化分頁查詢。
我們先從一個常用但性能很差的查詢來看一看。
SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15
這個查詢耗時0.00sec。So，這個查詢有什么問題呢？實(shí)際上，這個查詢語句和參數(shù)都沒有問題，因?yàn)樗玫搅讼旅姹淼闹麈I，而且只讀取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的執(zhí)行計(jì)劃可以發(fā)現(xiàn)該SQL檢索了100015行，但最后只需要15行。大的分頁偏移量會增加使用的數(shù)據(jù)，MySQL會將大量最終不會使用的數(shù)據(jù)加載到內(nèi)存中。就算我們假設(shè)大部分網(wǎng)站的用戶只訪問前幾頁數(shù)據(jù)，但少量的大的分頁偏移量的請求也會對整個系統(tǒng)造成危害。Facebook意識到了這一點(diǎn)，但Facebook并沒有為了每秒可以處理更多的請求而去優(yōu)化數(shù)據(jù)庫，而是將重心放在將請求響應(yīng)時間的方差變小。
對于分頁請求，還有一個信息也很重要，就是總共的記錄數(shù)。我們可以通過下面的查詢很容易的獲取總的記錄數(shù)。
SELECT COUNT(*)
FROM city;
然而，上面的SQL在采用InnoDB為存儲引擎時需要耗費(fèi)9.28sec。一個不正確的優(yōu)化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能夠在分頁查詢時事先準(zhǔn)備好符合條件的記錄數(shù)，隨后只要執(zhí)行一句 select FOUND_ROWS(); 就能獲得總記錄數(shù)。但是在大多數(shù)情況下，查詢語句簡短并不意味著性能的提高。不幸的是，這種分頁查詢方式在許多主流框架中都有用到，下面看看這個語句的查詢性能。
SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
這個語句耗時20.02sec，是上一個的兩倍。事實(shí)證明使用 SQL_CALC_FOUND_ROWS 做分頁是很糟糕的想法。
下面來看看到底如何優(yōu)化。文章分為兩部分，第一部分是如何獲取記錄的總數(shù)目，第二部分是獲取真正的記錄。
高效的計(jì)算行數(shù)
如果采用的引擎是MyISAM，可以直接執(zhí)行COUNT(*)去獲取行數(shù)即可。相似的，在堆表中也會將行數(shù)存儲到表的元信息中。但如果引擎是InnoDB情況就會復(fù)雜一些，因?yàn)镮nnoDB不保存表的具體行數(shù)。
我們可以將行數(shù)緩存起來，然后可以通過一個守護(hù)進(jìn)程定期更新或者用戶的某些操作導(dǎo)致緩存失效時，執(zhí)行下面的語句：
SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);
獲取記錄
下面進(jìn)入這篇文章最重要的部分，獲取分頁要展示的記錄。上面已經(jīng)說過了，大的偏移量會影響性能，所以我們要重寫查詢語句。為了演示，我們創(chuàng)建一個新的表“news”，按照時事性排序(最新發(fā)布的在最前面)，實(shí)現(xiàn)一個高性能的分頁。為了簡單，我們就假設(shè)最新發(fā)布的新聞的Id也是最大的。
CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;
一個比較高效的方式是基于用戶展示的最后一個新聞Id。查詢下一頁的語句如下，需要傳入當(dāng)前頁面展示的最后一個Id。
SELECT *
FROM news WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage
查詢上一頁的語句類似，只不過需要傳入當(dāng)前頁的第一個Id，并且要逆序。
SELECT *
FROM news WHERE id $last_id
ORDER BY id ASC
LIMIT $perpage
上面的查詢方式適合實(shí)現(xiàn)簡易的分頁，即不顯示具體的頁數(shù)導(dǎo)航，只顯示“上一頁”和“下一頁”，例如博客中頁腳顯示“上一頁”，“下一頁”的按鈕。但如果要實(shí)現(xiàn)真正的頁面導(dǎo)航還是很難的,下面看看另一種方式。
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;
通過上面的語句可以為每一個分頁的按鈕計(jì)算出一個offset對應(yīng)的id。這種方法還有一個好處。假設(shè)，網(wǎng)站上正在發(fā)布一片新的文章，那么所有文章的位置都會往后移一位，所以如果用戶在發(fā)布文章時換頁，那么他會看見一篇文章兩次。如果固定了每個按鈕的offset Id，這個問題就迎刃而解了。Mark Callaghan發(fā)表過一篇類似的博客，利用了組合索引和兩個位置變量，但是基本思想是一致的。
如果表中的記錄很少被刪除、修改，還可以將記錄對應(yīng)的頁碼存儲到表中，并在該列上創(chuàng)建合適的索引。采用這種方式，當(dāng)新增一個記錄的時候，需要執(zhí)行下面的查詢重新生成對應(yīng)的頁號。
SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;
當(dāng)然，也可以新增一個專用于分頁的表，可以用個后臺程序來維護(hù)。
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;
現(xiàn)在想獲取任意一頁的元素就很簡單了：
SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;
還有另外一種與上種方法比較相似的方法來做分頁，這種方式比較試用于數(shù)據(jù)集相對小，并且沒有可用的索引的情況下—比如處理搜索結(jié)果時。在一個普通的服務(wù)器上執(zhí)行下面的查詢，當(dāng)有2M條記錄時，要耗費(fèi)2sec左右。這種方式比較簡單，創(chuàng)建一個用來存儲所有Id的臨時表即可(這也是最耗費(fèi)性能的地方)。
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;
接下來就可以向下面一樣執(zhí)行分頁查詢了。
SELECT *
FROM _tmp
WHERE OFFSET = $offset
ORDER BY OFFSET
LIMIT $perpage;
簡單來說，對于分頁的優(yōu)化就是。。。避免數(shù)據(jù)量大時掃描過多的記錄。
我這里給你一個? 類似的例子,?? 表結(jié)構(gòu)也就是簡單的?? 分類,? 明細(xì).
要查詢每個分類下面,?? 隨機(jī)明細(xì)? 幾條的情況.
你可以參考參考.
測試表與測試數(shù)據(jù)。
CREATE?TABLE?test_order_by_rand?(group_code?varchar(10),?name?varchar(10));
INSERT?INTO?test_order_by_rand?VALUES('水果',?'蘋果');
INSERT?INTO?test_order_by_rand?VALUES('水果',?'梨子');
INSERT?INTO?test_order_by_rand?VALUES('水果',?'香蕉');
INSERT?INTO?test_order_by_rand?VALUES('水果',?'桃子');
INSERT?INTO?test_order_by_rand?VALUES('水果',?'菠蘿');
INSERT?INTO?test_order_by_rand?VALUES('蔬菜',?'蘿卜');
INSERT?INTO?test_order_by_rand?VALUES('蔬菜',?'白菜');
INSERT?INTO?test_order_by_rand?VALUES('蔬菜',?'蘑菇');
INSERT?INTO?test_order_by_rand?VALUES('蔬菜',?'毛豆');
INSERT?INTO?test_order_by_rand?VALUES('蔬菜',?'青椒');
INSERT?INTO?test_order_by_rand?VALUES('堅(jiān)果',?'核桃');
INSERT?INTO?test_order_by_rand?VALUES('堅(jiān)果',?'榛子');
INSERT?INTO?test_order_by_rand?VALUES('堅(jiān)果',?'杏仁');
INSERT?INTO?test_order_by_rand?VALUES('堅(jiān)果',?'花生');
INSERT?INTO?test_order_by_rand?VALUES('堅(jiān)果',?'開心果');
預(yù)期目標(biāo)，?按照?group_code?進(jìn)行分組，?每個分組內(nèi)，?進(jìn)行隨機(jī)獲取數(shù)據(jù).
SELECT
group_code,
name
FROM
(
SELECT
CASE?
WHEN?@cn?!=?group_code?THEN?@rownum:=?1?
ELSE?@rownum:=?@rownum?+?1??
END?AS?No,
group_code,
@cn?:=?group_code?AS?group_code,
name
FROM
(SELECT?@rownum:=0)?r,
(SELECT?@cn:=?'')?p,
(SELECT?*?FROM?test_order_by_rand?order?by?group_code,?rand())?tmp
)??subQuery
WHERE
No?=?3
ORDER?BY
group_code;
這里套了2層子查詢，?其中的
(SELECT?*?FROM?test_order_by_rand?order?by?group_code,?rand())?tmp??
用于實(shí)現(xiàn)，?針對每一個??group_code?進(jìn)行分組，?下屬的?name?的數(shù)據(jù)，?進(jìn)行隨機(jī)排序
其中的
(......)??subQuery
用于實(shí)現(xiàn)，?針對?前面的?按?group_code?分組，?name?隨機(jī)排序后的數(shù)據(jù)。
模擬一個??row_number()?over(partition?by?group_code)?的處理
最后的?No?=?3?用于限制，?每一個?group_code?下面，?顯示多少行.
執(zhí)行結(jié)果：
+------------+--------+
|?group_code?|?name???|
+------------+--------+
|?水果???????|?蘋果???|
|?水果???????|?香蕉???|
|?水果???????|?梨子???|
|?蔬菜???????|?青椒???|
|?蔬菜???????|?白菜???|
|?蔬菜???????|?蘑菇???|
|?堅(jiān)果???????|?核桃???|
|?堅(jiān)果???????|?花生???|
|?堅(jiān)果???????|?開心果?|
+------------+--------+
9?rows?in?set?(0.00?sec)
Mysql的分頁關(guān)鍵點(diǎn)在查詢時的 limit $iStart,$iEnd;//起初值與總長度
舉例：selece * from myTable1 order by id desc limit 0,10;
從0開始取前10條數(shù)據(jù)，取第二頁的內(nèi)容時，limit 10,10;即可
如有疑問去博客加好友，不清楚的再問我，有時間我再寫幾篇這樣的文章
重慶分公司
重慶分公司
