A. 網頁製作php+mysql如何學習
我看完php的語法，感覺對網頁製作沒什麼幫助--你這句話我能理解，也能看出你是一個辯證性思維比較強的人；我樂意為你解答你的問題。
你應該有過這樣的經歷吧，那就是你需要在某些網站里注冊，那麼為什麼你離開很多天甚至幾年後，你還是其中的會員呢？那就時因為你在注冊的時候你輸入的信息被存入到了資料庫，以PHP+MySQL為例來說，就是PHP有能力把你輸入的數據提交給資料庫，MySQL資料庫就存放了你的信息，等到你下次再登陸的時候呢，PHP就會到MySQL那裡去取出數據來。這些算是PHP對網頁製作的幫助吧？當然這個是比較淺顯的例子，很多論壇，留言板之類的都是通過PHP+MySQL構築的。
你的第二個問題，還需要什麼知識，首先就需要操作資料庫的知識，這里分兩點，第一點，就是對資料庫本身的認識，包括SQL語句，查詢優化，使用索引，安全性能，事務與鎖，許可權設置等等，當然，你開始的時候會DDL DML就可以了，如果這里提到的名詞你不是很清楚，你可以在網路上查查，那樣你會更加明了；第二點，就是使用PHP來訪問資料庫，你看完PHP語法，應該要有訪問資料庫這樣的章節才算完整。如果你學的PHP語法都是比較淺顯的，那麼你還需要更進一步，比如面向對象編程，緩存技術，靜態化技術之類的，你要是感覺作用或區別不大，那是因為你沒有充分考慮到如果是在大型項目中的情況。當然，需要的知識還很多，比如說PHP框架，JQuery之類的JS庫，Samrty之類用用於模板技術的庫等等。
你的第三個問題：之後該怎麼學。首先要對網路的常識要很清楚，比如HTTP協議，什麼是靜態網站，什麼是動態網站等等；再要清楚自己編寫靜態網頁以及美工方面的功底如何，能夠保證很熟練地獨立開發一個靜態網站來；至於這之後該怎麼學，上面說的那些就是你的任務，當然，你還需要進一步了解它們都是怎麼一回事，如果需要這樣做的話。
你的第四個問題：教材其實很多，也差不多，你有語言功底了以後看什麼都容易入門。當然，我看的是澳大利亞的一本PHP & MySQL web 開發第三版，雖然我買了這本書，不過我並不打算建議你去買，你要充分運用好網路資源，包括網路文庫，專業名站，視頻教材等等，另外，如果英語水平了得的話，建議你看英語原版。
希望你以後的學習會給你帶來更多快樂！
B. php redis做mysql的緩存，怎麼非同步redis同步到mysql資料庫
對於變化頻率非常快的數據來說，如果還選擇傳統的靜態緩存方式（Memocached、File System等）展示數據，可能在緩存的存取上會有很大的開銷，並不能很好的滿足需要，而Redis這樣基於內存的NoSQL資料庫，就非常適合擔任實時數據的容器。
但是往往又有數據可靠性的需求，採用MySQL作為數據存儲，不會因為內存問題而引起數據丟失，同時也可以利用關系資料庫的特性實現很多功能。
所以就會很自然的想到是否可以採用MySQL作為數據存儲引擎，Redis則作為Cache。而這種需求目前還沒有看到有特別成熟的解決方案或工具，因此採用Gearman+PHP+MySQL UDF的組合非同步實現MySQL到Redis的數據復制。
MySQL到Redis數據復制方案
無論MySQL還是Redis，自身都帶有數據同步的機制，比較常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog來實現的，這樣的數據復制其實還是一個非同步過程，只不過當伺服器都在同一內網時，非同步的延遲幾乎可以忽略。
那麼理論上也可以用同樣方式，分析MySQL的binlog文件並將數據插入Redis。但是這需要對binlog文件以及MySQL有非常深入的理解，同時由於binlog存在Statement/Row/Mixedlevel多種形式，分析binlog實現同步的工作量是非常大的。
因此這里選擇了一種開發成本更加低廉的方式，借用已經比較成熟的MySQL UDF，將MySQL數據首先放入Gearman中，然後通過一個自己編寫的PHP Gearman Worker，將數據同步到Redis。比分析binlog的方式增加了不少流程，但是實現成本更低，更容易操作。
Gearman的安裝與使用
Gearman是一個支持分布式的任務分發框架。設計簡潔，獲得了非常廣泛的支持。一個典型的Gearman應用包括以下這些部分：
Gearman Job Server：Gearman核心程序，需要編譯安裝並以守護進程形式運行在後台
Gearman Client：可以理解為任務的收件員，比如在後台執行一個發送郵件的任務，可以在程序中調用一個Gearman Client並傳入郵件的信息，然後就可以將執行結果立即展示給用戶，而任務本身會慢慢在後台運行。
Gearman Worker：任務的真正執行者，一般需要自己編寫具體邏輯並通過守護進程方式運行，Gearman Worker接收到Gearman Client傳遞的任務內容後，會按順序處理。
以前曾經介紹過類似的後台任務處理項目Resque。兩者的設計其實非常接近，簡單可以類比為：
Gearman Job Server：對應Resque的Redis部分
Gearman Client：對應Resque的Queue操作
Gearman Worker：對應Resque的Worker和Job
這里之所以選擇Gearman而不是Resque是因為Gearman提供了比較好用的MySQL UDF，工作量更小。
安裝Gearman及PHP Gearman擴展
以下均以Ubuntu12.04為例。
apt-get install gearman gearman-server libgearman-dev
檢查Gearman的運行狀況：
/etc/init.d/gearman-job-server status
* gearmand is running
說明Gearman已經安裝成功。
PHP的Gearman擴展可以通過pecl直接安裝
pecl install gearman
echo "extension=gearman.so">/etc/php5/conf.d/gearman.ini
service php5-fpm restart
但是實測發現ubuntu默認安裝的gearman版本過低，直接運行pecl install gearman會報錯
configure: error: libgearman version 1.1.0or later required
因此Gearman + PHP擴展建議通過編譯方式安裝，這里為了簡單說明，選擇安裝舊版本擴展：
pecl install gearman-1.0.3
Gearman + PHP實例
為了更容易理解後文Gearman的運行流程，這里不妨從一個最簡單的Gearman實例來說明，比如要進行一個文件處理的操作，首先編寫一個Gearman Client並命名為client.php：
<?php
$client =newGearmanClient();
$client->addServer();
$client->doBackground('writeLog','Log content');
echo '文件已經在後台操作';
運行這個文件，相當於模擬用戶請求一個Web頁面後，將處理結束的信息返回用戶：
php client.php
查看一下Gearman的狀況：
(echo status ; sleep 0.1)| netcat127.0.0.14730
可以看到輸出為
writeLog 100.
說明已經在Gearman中建立了一個名為writeLog的任務，並且有1個任務在隊列等待中。
而上面的4列分別代表當前的Gearman的運行狀態：
任務名稱
在等待隊列中的任務
正在運行的任務
正在運行的Worker進程
可以使用watch進行實時監控：
watch -n 1"(echo status; sleep 0.1) | nc 127.0.0.1 4730"
然後我們需要編寫一個Gearman Worker命名為worker.php：
<?php
$worker =newGearmanWorker();
$worker->addServer();
$worker->addFunction('writeLog','writeLog');while($worker->work());function writeLog($job){
$log = $job->workload();file_put_contents(__DIR__ .'/gearman.log', $log ." ", FILE_APPEND | LOCK_EX);}
Worker使用一個while死循環實現守護進程，運行
php worker.php
可以看到Gearman狀態變為：
writeLog 001
同時查看同目錄下gearman.log，內容應為從Client傳入的值Log content。
通過MySQL UDF + Trigger同步數據到Gearman
MySQL要實現與外部程序互通的最好方式還是通過MySQL UDF（MySQL user defined functions）來實現。為了讓MySQL能將數據傳入Gearman，這里使用了lib_mysqludf_json和gearman-mysql-udf的組合。
安裝lib_mysqludf_json
使用lib_mysqludf_json的原因是因為Gearman只接受字元串作為入口參數，可以通過lib_mysqludf_json將MySQL中的數據編碼為JSON字元串
apt-get install libmysqlclient-dev
wget https://github.com/mysqludf/lib_mysqludf_json/archive/master.zip
unzip master.zip
cd lib_mysqludf_json-master/
rm lib_mysqludf_json.so
gcc $(mysql_config --cflags)-shared -fPIC -o lib_mysqludf_json.so lib_mysqludf_json.c
可以看到重新編譯生成了 lib_mysqludf_json.so 文件，此時需要查看MySQL的插件安裝路徑：
mysql -u root -pPASSWORD --execute="show variables like '%plugin%';"+---------------+------------------------+|Variable_name|Value|+---------------+------------------------+| plugin_dir |/usr/lib/mysql/plugin/|+---------------+------------------------+
然後將 lib_mysqludf_json.so 文件復制到對應位置：
cp lib_mysqludf_json.so /usr/lib/mysql/plugin/
最後登入MySQL運行語句注冊UDF函數：
CREATE FUNCTION json_object RETURNS STRING SONAME 'lib_mysqludf_json.so';
安裝gearman-mysql-udf
方法幾乎一樣：
apt-get install libgearman-dev
wget https://launchpad.net/gearman-mysql-udf/trunk/0.6/+download/gearman-mysql-udf-0.6.tar.gz
tar -xzf gearman-mysql-udf-0.6.tar.gz
cd gearman-mysql-udf-0.6./configure --with-mysql=/usr/bin/mysql_config
-libdir=/usr/lib/mysql/plugin/
make && make install
登入MySQL運行語句注冊UDF函數：
CREATE FUNCTION gman_do_background RETURNS STRING SONAME 'libgearman_mysql_udf.so';
CREATE FUNCTION gman_servers_set RETURNS STRING SONAME 'libgearman_mysql_udf.so';
最後指定Gearman伺服器的信息：
SELECT gman_servers_set('127.0.0.1:4730');
通過MySQL觸發器實現數據同步
最終同步哪些數據，同步的條件，還是需要根據實際情況決定，比如將數據表data的數據在每次更新時同步，那麼編寫Trigger如下：
DELIMITER $$
CREATE TRIGGER datatoredis AFTER UPDATE ON data
FOR EACH ROW BEGIN
SET @ret=gman_do_background('syncToRedis', json_object(NEW.id as`id`, NEW.volume as`volume`));END$$
DELIMITER ;
嘗試在資料庫中更新一條數據查看Gearman是否生效。
Gearman PHP Worker將MySQL數據非同步復制到Redis
Redis作為時下當熱的NoSQL緩存解決方案無需過多介紹，其安裝及使用也非常簡單：
apt-get install redis-server
pecl install redis
echo "extension=redis.so">/etc/php5/conf.d/redis.ini
然後編寫一個Gearman Worker：redis_worker.php
#!/usr/bin/env php<?
$worker =newGearmanWorker();
$worker->addServer();
$worker->addFunction('syncToRedis','syncToRedis');
$redis =newRedis();
$redis->connect('127.0.0.1',6379);while($worker->work());function syncToRedis($job){global $redis;
$workString = $job->workload();
$work = json_decode($workString);if(!isset($work->id)){returnfalse;}
$redis->set($work->id, $workString);}
最後需要將Worker在後台運行：
nohup php redis_worker.php &
通過這種方式將MySQL數據復制到Redis，經測試單Worker基本可以瞬時完成。
C. php+mysql優化，百萬至千萬級快速分頁mysql性能到底能有多高
php+Mysql 優化，百萬至千萬級快速分頁
MySql 性能到底能有多高？用了php半年多，真正如此深入的去思考這個問題還是從前天開始。有過痛苦有過絕望，到現在充滿信心！MySql 這個資料庫絕對是適合dba級的高手去玩的，一般做一點1萬篇新聞的小型系統怎麼寫都可以，用xx框架可以實現快速開發。可是數據量到了10萬，百萬至千萬，他的性能還能那麼高嗎？一點小小的失誤，可能造成整個系統的改寫，甚至更本系統無法正常運行！好了，不那麼多廢話了。用事實說話，看例子：
數據表 collect ( id, title ,info ,vtype) 就這4個欄位，其中 title 用定長，info 用text, id 是逐漸，vtype是tinyint，vtype是索引。這是一個基本的新聞系統的簡單模型。現在往裡面填充數據，填充10萬篇新聞。
最後collect 為 10萬條記錄，資料庫表佔用硬碟1.6G。OK ,看下面這條sql語句：
select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的
select id,title from collect limit 90000,10; 從9萬條開始分頁，結果？
8-9秒完成，my god 哪出問題了？？？？其實要優化這條數據，網上找得到答案。看下面一條語句:
select id from collect order by id limit 90000,10; 很快，0.04秒就OK。為什麼？因為用了id主鍵做索引當然快。網上的改法是：
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;
這就是用了id做索引的結果。可是問題復雜那麼一點點，就完了。看下面的語句
select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！
到了這里我相信很多人會和我一樣，有崩潰感覺！vtype 做了索引了啊？怎麼會慢呢？vtype做了索引是不錯，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，從9萬開始，那就是0.05*90=4.5秒的速度了。和測試結果8-9秒到了一個數量級。從這里開始有人提出了分表的思路，這個和discuz 論壇是一樣的思路。思路如下：
建一個索引表： t (id,title,vtype) 並設置成定長，然後做分頁，分頁出結果再到 collect 裡面去找info 。 是否可行呢？實驗下就知道了。
10萬條記錄到 t(id,title,vtype) 里，數據表大小20M左右。用
select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。為什麼會這樣呢？我猜想是因為collect 數據太多，所以分頁要跑很長的路。limit 完全和數據表的大小有關的。其實這樣做還是全表掃描，只是因為數據量小，只有10萬才快。OK，來個瘋狂的實驗，加到100萬條，測試性能。
加了10倍的數據，馬上t表就到了200多M，而且是定長。還是剛才的查詢語句，時間是0.1-0.2秒完成！分表性能沒問題？錯！因為我們的limit還是9萬，所以快。給個大的，90萬開始
select id from t where vtype=1 order by id limit 900000,10; 看看結果，時間是1-2秒！
why 分表了時間還是這么長，非常之郁悶！有人說定長會提高limit的性能，開始我也以為，因為一條記錄的長度是固定的，mysql 應該可以算出90萬的位置才對啊？ 可是我們高估了mysql 的智能，他不是商務資料庫，事實證明定長和非定長對limit影響不大？怪不得有人說 discuz到了100萬條記錄就會很慢，我相信這是真的，這個和資料庫設計有關！
難道MySQL 無法突破100萬的限制嗎？？？到了100萬的分頁就真的到了極限？？？
答案是： NO !!!! 為什麼突破不了100萬是因為不會設計mysql造成的。下面介紹非分表法，來個瘋狂的測試！一張表搞定100萬記錄，並且10G 資料庫，如何快速分頁！
好了，我們的測試又回到 collect表，開始測試結論是： 30萬數據，用分表法可行，超過30萬他的速度會慢道你無法忍受！當然如果用分表+我這種方法，那是絕對完美的。但是用了我這種方法後，不用分表也可以完美解決！
答案就是：復合索引！有一次設計mysql索引的時候，無意中發現索引名字可以任取，可以選擇幾個欄位進來，這有什麼用呢？開始的select id from collect order by id limit 90000,10; 這么快就是因為走了索引，可是如果加了where 就不走索引了。抱著試試看的想法加了 search(vtype,id) 這樣的索引。然後測試
select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！
再測試: select id ,title from collect where vtype=1 limit 90000,10; 非常遺憾，8-9秒，沒走search索引！
再測試：search(id,vtype)，還是select id 這個語句，也非常遺憾，0.5秒。
綜上：如果對於有where 條件，又想走索引用limit的，必須設計一個索引，將where 放第一位，limit用到的主鍵放第2位，而且只能select 主鍵！
完美解決了分頁問題了。可以快速返回id就有希望優化limit ， 按這樣的邏輯，百萬級的limit 應該在0.0x秒就可以分完。看來mysql 語句的優化和索引時非常重要的！
好了，回到原題，如何將上面的研究成功快速應用於開發呢？如果用復合查詢，我的輕量級框架就沒的用了。分頁字元串還得自己寫，那多麻煩？這里再看一個例子，思路就出來了：
select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！
mygod ，mysql 的索引竟然對於in語句同樣有效！看來網上說in無法用索引是錯誤的！
有了這個結論，就可以很簡單的應用於輕量級框架了：
代碼如下：
$db=dblink();
$db->pagesize=20;
$sql="select id from collect where vtype=$vtype";
$db->execute($sql);
$strpage=$db->strpage(); //將分頁字元串保存在臨時變數，方便輸出
while($rs=$db->fetch_array()){
$strid.=$rs['id'].',';
}
$strid=substr($strid,0,strlen($strid)-1); //構造出id字元串
$db->pagesize=0; //很關鍵，在不注銷類的情況下，將分頁清空，這樣只需要用一次資料庫連接，不需要再開；
$db->execute("select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)");
< php while($rs=$db->fetch_array()): >
<tr>
<td$amp;>amp;$amp;nbsp;< php echo $rs['id']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['url']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['sTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['gTime']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['vtype']; $amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;<a act=show&id=< php echo $rs['id']; $amp;>quot;$ target="_blank"$amp;>amp;$lt; php echo $rs['title']; $amp;>amp;$lt;/a$amp;>amp;$lt;/td>
<td$amp;>amp;$amp;nbsp;< php echo $rs['tag']; $amp;>amp;$lt;/td>
</tr>
< php endwhile; >
</table>
< php
echo $strpage;
通過簡單的變換，其實思路很簡單：1）通過優化索引，找出id，並拼成 "123,90000,12000" 這樣的字元串。2）第2次查詢找出結果。
小小的索引+一點點的改動就使mysql 可以支持百萬甚至千萬級的高效分頁！
通過這里的例子，我反思了一點：對於大型系統，PHP千萬不能用框架，尤其是那種連sql語句都看不到的框架！因為開始對於我的輕量級框架都差點崩潰！只適合小型應用的快速開發，對於ERP,OA，大型網站，數據層包括邏輯層的東西都不能用框架。如果程序員失去了對sql語句的把控，那項目的風險將會成幾何級數增加！尤其是用mysql 的時候，mysql 一定需要專業的dba 才可以發揮他的最佳性能。一個索引所造成的性能差別可能是上千倍！
PS: 經過實際測試，到了100萬的數據，160萬數據，15G表，190M索引，就算走索引，limit都得0.49秒。所以分頁最好別讓別人看到10萬條以後的數據，要不然會很慢！就算用索引。經過這樣的優化，mysql到了百萬級分頁是個極限！但有這樣的成績已經很不錯，如果你是用sqlserver肯定卡死！而 160萬的數據用 id in (str) 很快，基本還是0秒。如果這樣，千萬級的數據，mysql應該也很容易應付。
D. php+mysql可以處理億級的數據嗎
理論上是可以的，但效率上就有問題了，這么大量的數據一般不會放一張表裡面，都會考慮分表，然後考慮索引、資料庫主從、伺服器配置等，提高查詢效率php+mysql可以處理億級的數據嗎