[计数] 请问在论坛里怎么计算每个帖子的点计量的？？

powerpolly

讲的经典，俺也知道论坛的贴子访问记数问题是比较头疼的，目前较好的方法还是楼上说的在数据库里面用一个属性来记录，因为每次搜索该主题的时间是个瓶颈，然后再在另一个表中查询所有该主题的回复，也是瓶颈。而计数可以这样考虑：把update操作合并到select中，因为update操作就包括select，每次对该主题的请求，直接用update。
楼上觉得怎么样？

SATAND

如果你这样子的话，就相当于每个select都是单线进行的
你觉得怎么样呢？

powerpolly

很快就发现这样是不行的，因为这涉及到数据库的查询机制，就是说如果只用update，但必须取出该主题记录的数据啊，还得用一次select，如果数据库系统能在select到该记录时，判断如果紧接着update操作，则不需要再次select，这样应该是最具时间性能的，但对MYSQL的查询机制也不了解，结果也就不得而知了。

北京野狼

[quote]原帖由 "powerpolly"]很快就发现这样是不行的，因为这涉及到数据库的查询机制，就是说如果只用update，但必须取出该主题记录的数据啊，还得用一次select，如果数据库系统能在select到该记录时，判断如果紧接着update操作，则不需要再次se..........[/quote 发表：


嘿嘿，没看懂说什么

powerpolly

目前的事实是：大部分论坛都是用野狼兄这种方法（在数据库里加字段），用文本文件来读写是不可取的，因为有多少个帖子在点击，就有多少个文件I/O，而文件是操作系统来调度，不管是每个贴子对应一个记数文件，还是共用一个文件，频繁的I/O请求会使操作系统疲于应付，想明确的问题是：那为什么数据库能够胜任呢？
    在于任何数据库系统都有自己的查询优化，特别是游标机制，查询的瓶颈在于找到对应该记录的游标指针，我们可以做一个实验：用同一条命令先后查同一记录，第二次花费时间绝对比第一次短！就是游标的作用。
    难道没看懂what I said? update包含了select和I/O，而最费时的不是I/O而是select，所以在n个select后面来一个update，按照游标机制，此时只需要来一次I/O即可。所以开销很小。

SATAND

[quote]原帖由 "powerpolly"]目前的事实是：大部分论坛都是用野狼兄这种方法（在数据库里加字段），用文本文件来读写是不可取的，因为有多少个帖子在点击，就有多少个文件I/O，而文件是操作系统来调度，不管是每个贴子对应一个记数文件，还是共?.........[/quote 发表：


呵呵，兄弟，你知道select为什么或被饿死吗？
偶然的一批被饿死是允许的，但是当这种现象成为习惯——比如计数，是一个频繁的操作，则此操作碰上长时间的select的可能性就会非常大，则select被饿死的几率会非常大——假设一天遇到了10次，每次影响120次select操作....
这样的论坛，就是失败的程序

我想，如果计数使用另1张表，则可行的多，毕竟偶然检索不出浏览数量对论坛的影响非常小

北京野狼

原帖由 "SATAND" 发表：


呵呵，兄弟，你知道select为什么或被饿死吗？
偶然的一批被饿死是允许的，但是当这种现象成为习惯——比如计数，是一个频繁的操作，则此操作碰上长时间的select的可能性就会非常大，则select被饿死的几率会非常?.........

你所顾虑的不是问题，真不想再讨论这个了。
你那篇文章最大的错误就是说mysql表级锁定。
早期mysql表级是对用户来说的，mysql自己的服务程序不是这样的.
表文件被分成很多个区。我们普通的fopen打开文件只能有一个句柄写入。但是如果你直接写硬盘的逻辑块就没什么句柄的概念。
就好像你定义一个char * pStr = string[100]就如同open的句柄。但是
如果你定义100个指针每个指针仅仅写一个元素，就根本不互相冲突。

你分多少个表也毫无意义，同样存在着多个读遭遇一个写的问题。
记录点击数量只是如何系统最小的问题，连这个都干不了，那世界上就没有什么论坛系统了。
存在的就是合理的，那么多大访问量的数据库系统都好好的，我们就没必要顾虑这

SATAND

通过模拟环境测试，表级锁定是存在的。
当然，MySQL支持你所说的理想状态，那就是行级锁定，但是，对innodb的新功能没有必需的应用，而且在传统的应用中，效率也没有想象的那么好。
我所讨论的话题，是指访问量N大后的计数，而你考虑的，只是一个小论坛的计数。
你提到的“大访问量的数据库系统”，不知道你见过几个——注意，是大访问量数据库而不是大数据量库。我曾接触过几个，其中，电信、南航的都是集群。
而我对MySQL的负载研究，也是基于实际出发的。ytht.net，不知道大家是否听说过，但是已经倒下了。当年ytht同时在线达数万，只有一台服务器。曾经想过为ytht每帖计数，但是经模拟环境测试（我们使用过虚拟主机、游戏服务端，甚至用格式化Ddos攻击模拟大访问量）MySQL不能够在这么艰苦的环境下完成使命。
之所以不能，就是因为我所说的select饿死的问题频繁发生。

“记录点击数量只是如何系统最小的问题”，在此小问题上，select饿死算是极端，性能滞值为100%，假设此时的访问量 10000 person-s，实践证明，其值到不了这个数就会出问题。那么，当一个中级论坛访问量为 500 person-s 时（只要上点规模就能达到，如果达不到，参考台湾的情色BBS规模），那么因为数据读写造成的性能滞值就是 5%，为了偷懒，使用数据表给每帖计数，向论坛完全崩溃迈进5%，是否值得呢？换种说法，只要做一个复杂点的应用，就能提升5%的性能，是否值得呢？
如果谁觉得不值得，那就不要自technician，改称coder得了。

北京野狼

原帖由 "SATAND" 发表：
通过模拟环境测试，表级锁定是存在的。
当然，MySQL支持你所说的理想状态，那就是行级锁定，但是，对innodb的新功能没有必需的应用，而且在传统的应用中，效率也没有想象的那么好。
我所讨论的话题，是指访问量N大..........

一直胡说八道。那你给个方案记录点击数量。
这世界上从没有那个论坛能有几万在线，表级锁定是对mysql用户的，mysql管理程序不存在表级锁定的。我说的方法也是针对mysql自己。再怎么集群，都存在同一个表多个读遭遇一个写的问题。
按你的意思这都是无法解决的问题了。

记录点击数量当然是最小的问题，一个论坛系统读写数据库的地方多着呢。
如果解决不了读写的问题，只能是服务器太差，和数据库没有关系。没有任何其他的办法比用数据库处理读写更有效。
端正你的说话态度

SATAND

[quote]原帖由 "北京野狼"]一直胡说八道。......[/quote 发表：


本着讨论的原则，我建议你对这句话道歉。

再，你一再说计数是个小问题，但是有没有考虑每次浏览就是一次update呢

另，我虽没有通读mysql的源码，但是用过嵌入式mysql写过软网关，我觉得在mysql内部机制方面我比你甚至一些国内原创的主观臆断的说明更有发言权。

最后，此问题到此为止，我提出我的观点，技术上你是否采用，与我无关。