关于php引用mysql建立高速内存表的感想

lzhome

mysql能够建立memory内存表，完全将表建立于内存。
在我目前的项目中，对于上百行固定数组，原来是建立
在php脚本中，现在建立在这种内存表中，感觉的确速度
提升很多。即使是联动菜单，原来用js脚本，现在替换成
用户直接读这个内存表实现联动，也感觉很有优越性。

不知道大家用过没用过这种技术，说说体会吧。

rf123

用了很久了，从heap表开始就用了
速度是很快，但限制也很多，重启mysql后会把所有数据清空
用在不是很重要数据存储比较好，类似聊天室，点击数统计等

HonestQiao

例如：session就可以这么使用。

wsswan

你数据库是 Localhost 吧，本地当然快了，以后机器多了你会发现网络 I/O 还没有磁盘 I/O 块呢。SQLIte 有 memory 类型的表你可以用，比 MySQL 还快些。

PHP 的 IPC，除了共享内存外也没什么好办法，不过 PHP 的 shm 可操作性如何还很难说。不如直接存到 /dev/shm/ 里，反正也是内存，FS 肯定吞吐肯定要比 DB 快。多台机器就做个 memcache ，无非也就是个 socket 共享罢了。

james.liu

原帖由 wsswan 于 2006-12-13 11:27 发表
你数据库是 Localhost 吧，本地当然快了，以后机器多了你会发现网络 I/O 还没有磁盘 I/O 块呢。

网络i/o，，，你指哪部分呢？

Namelessxp

原帖由 james.liu 于 2006-12-13 11:59 发表



网络i/o，，，你指哪部分呢？

估计是指远程数据库的通信开销

wsswan

原帖由 james.liu 于 2006-12-13 11:59 发表



网络i/o，，，你指哪部分呢？

就是从 Client 的 tcp 层到 Server 的 tcp 层这中间的部分。网络的 TTL 延迟是以秒计算的(响应时间怎么算忘了……不过肯定比硬盘满好几个数量级)，硬盘的寻址时间是微妙。 现在普通的 100BaseT 的带宽是 100Mbps / 8bit+1crc ~> 10MBps， 10MBps 的硬盘恐怕没人敢用吧……

[ 本帖最后由 wsswan 于 2006-12-13 14:17 编辑 ]

lzhome

原帖由 wsswan 于 2006-12-13 11:27 发表
你数据库是 Localhost 吧，本地当然快了，以后机器多了你会发现网络 I/O 还没有磁盘 I/O 块呢。SQLIte 有 memory 类型的表你可以用，比 MySQL 还快些。

PHP 的 IPC，除了共享内存外也没什么好办法，不过 PHP 的 ...

sqlite 是微型数据库，若非要比速度，的确比mysql还快些，但是，对于多线程支持，sqlite实在差的太远太远，sqlite官方文档中已经明确指出，对于多线程的网络访问，还是不要用sqlite，呵呵

james.liu

原帖由 wsswan 于 2006-12-13 14:13 发表


就是从 Client 的 tcp 层到 Server 的 tcp 层这中间的部分。网络的 TTL 延迟是以秒计算的(响应时间怎么算忘了……不过肯定比硬盘满好几个数量级)，硬盘的寻址时间是微妙。 现在普通的 100BaseT 的带宽是 100M ...

哦，，应该指服务器端分布把。。。

服务器端分布有一定好处，硬件资源，网络，软件资源的合理利用。

你说得慢，，我不知道你怎么计算的。 当内存占用和cpu占用达到一定比例，读盘速度不快的。这点我深有感触。

"两台普通机器运行的服务肯定比一台稍微好点的机器快，稳定"，，大概这么个意思

这话不是我说得，，，是livejo什么的网站总结的。。。

wsswan

原帖由 lzhome 于 2006-12-13 16:18 发表


sqlite 是微型数据库，若非要比速度，的确比mysql还快些，但是，对于多线程支持，sqlite实在差的太远太远，sqlite官方文档中已经明确指出，对于多线程的网络访问，还是不要用sqlite，呵呵

PHP 如果支持 thread 那 Java 真就一边凉快去了，实际上 PHP Group 连 child process 都不敢保证安全……而且 MySQL 在 create table xxx{}type=memory  的时候好像还没 SQLite 的 memory 大呢：）

当然我补一句啊，我假设楼主是 localhost........

[ 本帖最后由 wsswan 于 2006-12-13 18:04 编辑 ]