66666666666666666666666666666666666666

5000千万主题

http://free.hyphp.cn/

数据库就是数据库  没有程序能真正承载什么亿千万数据  都靠静态缓存和数据库的条件设计

@admin:回复 #2 5000千万主题http://free.hyphp.cn/数据库就是数据库 没有程序能真正承载什么亿千万数据 都靠静态缓存和数据库的条件设计

环境是Apache2.4+php7+Memcached+mariadb5.5(OneinStack一键包)

刚刚测试了一下，新建HYBBS 1.4.0.5按下升级1.4.0.6，
全新状态的HYBBS，0 主题 页面开启相当流畅。。

然后在adminer下搬移hy_post  hy_thread的一部分50多万主题 到新建立的HYBBS，

数据搬移完成后就非常严重的延迟，所以应该还是主题数据造成的。

原因已经查明

四栏插件的一个 SQL语句 存在缺陷

img[!]=>''   该语句在大数据会造成严重的 查询时间.  

如果你在测试中不使用该插件 就不会造成严重的查询时间了

6666666666

刚刚移除四栏插件，似乎有点效果少了一半耗时

现在运行耗时：25.7686 s

重新整理有时会降到最少12 s

可能还有地方存在问题。

但应该就不是插件，因为我试过全删插件依然耗时20多秒。

查看一下 右下角窗口 调试窗口

看一下SQL执行  哪句比较耗时

@admin



全都显示0ms，但是我开好久好久....

• SQL查询 (24)
• 连接数据库 [耗时] 0.013ms
• SELECT * FROM "hy_user" WHERE "id" = '1' LIMIT 1 [耗时] 0ms
• SELECT * FROM "hy_forum" [耗时] 0ms
• SELECT * FROM "hy_usergroup" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_post" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_thread" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_user" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_thread" WHERE "atime" > 1469203200 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_post" WHERE "atime" > 1469203200 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_user" WHERE "atime" > 1469203200 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• DELETE FROM "hy_ol" WHERE "atime" < 1469275687 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• DELETE FROM "hy_ol" WHERE "atime" < 1469275687 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• SELECT * FROM "hy_thread" ORDER BY "btime" DESC LIMIT 10 [耗时] 0ms
• SELECT * FROM "hy_thread" WHERE "img" != '' ORDER BY "id" DESC LIMIT 10 [耗时] 0ms
• SELECT * FROM "hy_thread" ORDER BY "posts" DESC LIMIT 10 [耗时] 0ms
• SELECT * FROM "hy_thread" WHERE "id" = 1 LIMIT 1 [耗时] 0ms
• SELECT "user" FROM "hy_user" WHERE "id" = '1' LIMIT 1 [耗时] 0ms
• SELECT * FROM "hy_post" WHERE "tid" = 1 AND "isthread" = 1 LIMIT 1 [耗时] 0ms
• SELECT * FROM "hy_post" WHERE "tid" = 1 AND "isthread" = 0 ORDER BY "id" LIMIT 0,10 [耗时] 0ms
• SELECT * FROM "hy_fileinfo" WHERE "tid" = 1 [耗时] 0ms
• SELECT EXISTS(SELECT 1 FROM "hy_post" WHERE "uid" = '1' AND "tid" = 1) [耗时] 0ms
• UPDATE "hy_thread" SET "views" = "views" + 1 WHERE "id" = 1 [耗时] 0ms

你先修复一下 0ms的问题

/HY/HY_SQL.php

104行处

public function query($query)
    {
        if ($this->debug_mode) {
            echo $query;
            $this->debug_mode = false;
            return false;
        }
        array_push($this->logs, $query);
        
        $re = $this->pdo->query($query);
        if (C('DEBUG_PAGE')) {
            $a = microtime(TRUE);
            DEBUG_SQL::SQL_LOG($query . ' [耗时] ' . round(microtime(TRUE) - $a, 4) . 'ms');
        }
        return $re;
    }

改为

public function query($query)
    {
        if ($this->debug_mode) {
            echo $query;
            $this->debug_mode = false;
            return false;
        }
        array_push($this->logs, $query);
        $a = microtime(TRUE);
        $re = $this->pdo->query($query);
        if (C('DEBUG_PAGE')) {
            
            DEBUG_SQL::SQL_LOG($query . ' [耗时] ' . round(microtime(TRUE) - $a, 4) . 'ms');
        }
        return $re;
    }

接着下面的exec函数

public function exec($query) 
    {
        if ($this->debug_mode) {
            echo $query;
            $this->debug_mode = false;
            return false;
        }
        array_push($this->logs, $query);
        
        $re = $this->pdo->exec($query);
        if (C('DEBUG_PAGE')) {
            $a = microtime(TRUE);
            DEBUG_SQL::SQL_LOG($query . ' [耗时] ' . round(microtime(TRUE) - $a, 4) . 'ms');
        }
        return $re;
    }

改为

public function exec($query) 
    {
        if ($this->debug_mode) {
            echo $query;
            $this->debug_mode = false;
            return false;
        }
        array_push($this->logs, $query);
        $a = microtime(TRUE);
        $re = $this->pdo->exec($query);
        if (C('DEBUG_PAGE')) {
            
            DEBUG_SQL::SQL_LOG($query . ' [耗时] ' . round(microtime(TRUE) - $a, 4) . 'ms');
        }
        return $re;
    }

这是我之前做耗时 的一个if 失误

@admin
主题页面

后台

(话说进后台也会跑hy_thread,hy_post表会不会有点浪费资源)

按我说的 尝试增加索引:

hy_thread , hy_post , hy_user ,hy_ol 的 atime字段 增加index 索引

ht_thread 的 btime , posts 增加index索引

列表中的 img!=''消耗巨大 因为他是字符类型 这个请先关闭插件

我觉得有些SQL语法，要不要参考Carbon论坛的做法。

类似

主题>50000主题时就节约资源搜寻语法， 

主题<50000就用比较进阶的搜寻语法....

先解决 索引的问题

主题搜索的问题 后期优化上去

@admin
我的意思是那些语法可以用类似的方式对较多数据的用户减少整体消耗，不是单单指搜索。

(例如可以增加个判断或后台增加开关，对于百万数据的论坛，

如果某主题的View大于如十万多少，就不触发UPDATE "views" + 1 ，
然后hy_thread对于超过十万的就直接改显示"形容很多"或是约略的"十万以上"，
毕竟每个增加views累积起来也是小负担，而且我看一下常常都0.X s以上，有时候还会突然暴增延时。。)

另外想问一下，atime是指发文时间?
可不可以提示一下修改位置可以暂时注解掉不显示看看是否会顺畅许多? 

还有好像 s & ms 单位很多是错的，另外HY_SQL.php的修复好像没放入1.4.0.7更新中。

2个牛人

@ical:回复 #5 2个牛人

update views+1 并不会很大影响 

没办法 只能到达10万 就不++ 了 那何来 20万呢  其实还是得++ 

update 整数+1 还是很快的 

论坛数据结构很多处的 atime都是指内容的插入时间 . btime 一般只 最后更新时间

这样的反馈才是hybbs所需要的，像我们的这样数据有限的触发不了隐藏任务

解决大半了，现在"微慢"而已。

即使atime字段 增加index 索引，缓存开启的状态下atime一个依然要0.8187ms。

等于50多万笔光主题hy_post +hy_thread 就耗掉1秒多，

 如再加上回复与注册依然会上升到好几秒。

一个页面要好几秒开启，显然不大符合生产应用。

不知@admin 能不能改善一下写法之类，尽量降低atime延迟。 
--------------------------

http://free.hyphp.cn/ 解决索引后的 100万主题

@admin
确实索引加进去了，也确实变快了，但是依然无法达到你的那种效果。

这个HYBB除安装BLOG模板，home插件，sitemap插件，关闭注册用户，侧边栏-增加HTML代码。

我唯一只在资料库中增加id自动递增，如图片那样，然后搬移主题数据，也没忘了索引。。

其馀都是 置顶那个完全崭新的 那个HYBBS1.4.0.8，而不是升级的。

会不会是因为我的atime都不一样。 而你的atime的unix时间戳都是"0" ? (我不懂这个，猜测..)

线上硬件测试一下吧.

这是100万主题的  atime 范围 count 

在phpmyadmin中 执行 SELECT COUNT(*) FROM "hy_thread" WHERE "atime" > 1469289600

注意上面的 单位是 (微妙) (µs)  

也就是说这种查询 是微乎其微的速度

• SQL查询 (20)
• 连接数据库 [耗时] 0.0002ms
• SELECT * FROM "hy_user" WHERE "id" = '1' LIMIT 1 [耗时] 0.0001ms
• SELECT * FROM "hy_forum" [耗时] 0.0001ms
• SELECT * FROM "hy_usergroup" [耗时] 0.0001ms
• SELECT COUNT(*) FROM "hy_post" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_thread" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_user" [耗时] 0ms
• SELECT COUNT(*) FROM "hy_thread" WHERE "atime" > 1469289600 [耗时] 0.0001ms
• SELECT COUNT(*) FROM "hy_post" WHERE "atime" > 1469289600 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_user" WHERE "atime" > 1469289600 [耗时] 0ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• DELETE FROM "hy_ol" WHERE "atime" < 1469341428 [耗时] 0.0002ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• DELETE FROM "hy_ol" WHERE "atime" < 1469341428 [耗时] 0.0001ms
• SELECT COUNT(*) FROM "hy_ol" [耗时] 0ms
• SELECT * FROM "hy_thread" WHERE "img_count" != 0 ORDER BY "id" DESC LIMIT 0,5 [耗时] 0.0001ms
• SELECT * FROM "hy_thread" WHERE "atime" > 1468736828 ORDER BY "views" DESC LIMIT 0,10 [耗时] 0.0004ms
• SELECT "user" FROM "hy_user" WHERE "id" = '1' LIMIT 1 [耗时] 0ms
• SELECT "user" FROM "hy_user" WHERE "id" = '2' LIMIT 1 [耗时] 0ms
• SELECT * FROM "hy_thread" WHERE "atime" > 1468736828 ORDER BY "posts" DESC LIMIT 0,10 [耗时] 0.0002ms
• SELECT * FROM "hy_thread" WHERE "atime" > 1468736828 ORDER BY "goods" DESC LIMIT 0,10 [耗时] 0.0003ms

因为我的数据测试时间戳用系统时间产生的。所以atime 是00:00:00后。

例如1469343600

而 "atime" > 1469289600，会COUNT出 大于 2016/7/24 00:00:00的次数。

我以系统时间戳产生了50万笔，就会++50万次，造成开启缓慢。
所以修了一下

• SELECT COUNT(*) FROM "hy_thread" WHERE "atime" > 1469289600 [耗时] 0.0001ms
• SELECT COUNT(*) FROM "hy_post" WHERE "atime" > 1469289600 [耗时] 0.0001ms
• SELECT COUNT(*) FROM "hy_user" WHERE "atime" > 1469289600 [耗时] 0.0002ms

话说...加总atime>1469289600的意义在于?

我的100万数据 也是 当日生成的  时间也是0  atime时间条件也是满足 100万条的 

你问的这条SQL是用于 统计当日发帖数量的 

看你这张图的性能分析

Send Data 用了400多ms

这是 mysql发送到 php 传输管道的用时 

首先count这是一个统计 发送的数据并不大 却用了 那么大的时间 

应该是本地环境的问题!

@admin:回复 #2 线上硬件测试一下吧.

如果是为了统计不需要每次都触发，另建表储存统计资料。而统计资料可以SELECT COUNT(*) ，但不用时时刻刻吧? 就好像另一个轻论坛的就是这样做减缓消耗。 很多定时，或是点击次数每100才触发。这样就没这个问题了。。

并外可能有部分本地环境问题，因为我真的不懂my.cnf要怎么设，可能是这个影响到。还有IO可能不是很好，虽然是SSD但VirtualBox模拟出来的Centos8.

但也不是完全是本地环境问题....

因为我的时间戳原本不是0...这才是改0之后的。

由于你本地开启了DEBUG模式  所以数据没被缓存 

所以造成了 每次访问都会查询 

@admin

http://free.hyphp.cn/

可以atime全改成1469376000，我参考看看吗?....。

另外这样应该是没开DEBUG模式吧，依然跑了count阿~~

已增加 100万主题 1469376000 时间戳 

你这时间戳时 明天凌晨

看样子只有我的会比较慢还一直查询，我还是直接注解掉统计好了。

就这样...

http://free.hyphp.cn/

又加了 100万主题 并 atime 使用随机数

不知原因他就是一直Count...

已放弃.....HYBBS.php//已注解掉统计。