從 source 追蹤看起來 ,
mysql 的 mysql_store_result 是會把所有資料都讀出來,
而且裡面都是用 ALLOC_ROOT 來 allocate 記憶體,
所以不會用到 PHP 的 Share Memory.
shirock 這部份說的應該沒錯.

Fiend 習慣的寫法,
是用
$res = mysql_query($db,$query);
$row_count = mysql_num_rows($res);
當然一個 query 就解決了.

我想這是常常被忽略的部份.
中小型的專案這樣做當然是 ok 的.

只是像我現在處理的Case,
大概要考慮部份要調整成用 mysql_unbuffered_query ,
拆成兩個 query 也許對我更適合.

我的 C 不太好，從 PHP 的 Source Code 看不出什麼所以然。因此我按照 FIEND 的方法做了個實驗，來驗證一下他前面的說法：

http://blog.roodo.com/jaceju/archives/4991595.html

有興趣的朋友就參考看看吧。

這篇討論我就關注到這裡了。

引用:

應該不是.
執行 mysql_store_result 的時候,
在 result 和每一筆 record 都會多一個 Header 的空間,
大小不一定(看 field count).

所以使用的記憶體會比實際 mysql table 大.
在 source 中沒有看到任何 compress 的動作.


mysql 的這個流程讓我嚇一跳,
以往大部份用的是 mssql 和 oracle,
在 client 和 server 間的 data cache 機制都做得比較好,
看起來 mysql 像是把結果算出來後就直接全部丟出來.

所以使用 mysql 要比用 mssql 或oracle 要來得更小心一點.

這串 討論串 愈來愈精彩了... ccc

辨論這麼久 只有我用屁股想事情 沒有去做測試和看原始碼 .

我看 c 的速度沒有 norman 快 , 要花時間慢慢看 , 所以先做實驗.

jaceju 提出 實驗數據 , 我覺得上述 實驗的方式 條件還不夠明朗 .

不過實驗結果 與 mssql 和 oracle 比較起來 蠻讓人吃驚的 .


這樣的實驗結果...無彩我這麼 支持 mysql 不會佔用 php 端記憶體.

可是 我還是不服氣 query record 內容 會全部 放到 php 的 memory

這樣就不可能 table 內容到達 g 的資料量 不用 limit 還拉的回來??

照上述的實驗結果應該會直接撐爆記憶體 error .....


所以 ~ 我又做了個實驗 直接拉二台伺服器 :

我覺得 資料筆數 造成的 php 消化的記憶體量 並不能 證明 query 不下 limit 的內容全部放入 php 的記憶體內 但是 不排除會往 php 丟.


所以 以 少量的筆數 去製造 非常大的 資料佔用空間 反而才可以證明 內容不會全數佔用在 php 記憶體上.


條件 :

我將資料大小灌到最大 設一個 text field 採用 連續不斷的英文字 content field 全都匯入 512k 大小的 資料量 .

server 1 : mysql server
memory : 1 g .
swqp : 1g

server2 : php server
memory : 1g .
swap : 1g .


用 php server 去拉 mysql server 的資料.. 來看看 php server 所佔用的 記憶體大小.

####

只要 php 不下 limit 的條件下可以 從遠端 mysql 可以拉回 一些 資料 ,

就可以反駁 query 的內容 會全部放到 php 管不到的 記憶體 區塊 而還可以 直接 count 出 php 記憶體求出筆數的講法.


現在 我在 4 萬筆資料上 我將 content 塞入 512k 連續不斷的英文字 .


(塞資料塞了很多時間 昏倒.... (40000 * 512 k) )

+---------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| content | text | NO | | NULL | |
+---------+------------------+------+-----+---------+----------------+

總計資料庫大小 : 2.4 g



實驗目地：

驗證 php 透過 api 下 mysql query 完後 不會將 record 內容全部放在 php 記憶體內 供 php 使用 .


實驗結果 :

php server 端 下 對 sql server 端 用 php 程式 下 query 但是不下 limit


確實 php server 的 被 php 大量佔用了 , 可是 一開始

php 並沒有吃到 2.4 g 記憶體 而是 爆衝到 700 多 mb 一口氣全都吃完 server 最後的記憶體 ....

之後 掉到 30 mb 之後 維持一段很長的時間 在 35 mb 不變 .

直到最後它才 把我要的十筆資料要出來.

後續的表現 發現 它的buffer 會慢慢變小 之後維持一個 小量 然後到把資料拉出來為止 .



感言 :

不管如何 我開始美爽爽 php 一開始開這麼大的 buffer 來 存放 query 回應的資料 .

也許是 php 為了應付 mysql api 端的設計 .

這驗證了 在 php + mysql 上 , 不下 limit , api 會佔用 很大的記憶體量 是事實 .

而 這樣在設計上 打破我對一般 db 常理的認知 , 注意到 php 佔用大量記憶體的問題.



推論 :

( 這裡我下一個推論 有空我會翻翻原始碼 也許有錯 )

mysql 在 query 一下完 就會將 record 的 結果 全丟給 遠端或近端 php 連結 mysql 的 api , 而 也許 php api 這端 將 record 快取到了 硬碟上 或是 它只是拉進來 api 做演算 , 但實驗到這裡 花了一些時間塞資料　所以有點懶得再去觀查 硬碟的變化量 .

不可否認的是 不下 limit 在 大量的 record數下　確實會造成 php 記憶體爆衝 .

但可以知道的是 record 內容 並不會 全數會放進 php memory 讓 php 記憶體可以有被撐爆的可能性 也不會讓 php 以 計算本身記憶體的特性 利用 php count() 的方式 取用 record 筆數 .

沒有辦法幫忙實驗，找了一些相關文章：
http://www-128.ibm.com/developerworks ... a=dgr-lnxw09PHP5.2-Memory
http://www.ghastlyfop.com/blog/2008/0 ... formance-for-dummies.html
http://www.mysqlperformanceblog.com/

對於 mysql_query() 會傳回大量資料的問題，過去在 XOOPS 有遇到過，因為早期版本的設計也許基於類似使用 mssql 或oracle 之類其他 DBMS 的經驗，每次都要將資料全都拖回來做運算，所以資料量幾千筆就會超過系統限制而出現錯誤訊息；不過我並沒有像上述諸公這樣子實驗推敲，只是給自己一個可以接受的理由，把一個問題處理掉後就繼續處理下一個問題。 ^^||

感謝各位提供的資訊，我只是透過灌水繼續拉長這篇討論 :)

這一篇...可以說大家都很努力阿.. ^_^ ..

個人看法，每個資料庫都有他的特性，個人傾向在開發上，盡量簡化 php 負責部份，所以基本上也都是以所謂兩次 SQL 的方式去跟 MySQL 作處理。

而其他像是 Oracle , MSSQL 等或許各有各的比較好的作法，我想依照不同的資料庫應用不同的作法，發揮各自資料庫的效能，或許是比較好的作法吧。