关于Discuz X2及X2.5的一些建议

本文因为某问题因而在我个人空间中被管理隐藏不显示，故存档于 http://xiaozhong.biz/thread-272-1-1.html

1、关于帖子的图片动态加载（滚动到浏览器窗口可见范围内才加载）功能对于缓解服务器压力很不错，但在本论坛（https://discuz.dismall.com）浏览发现此功能对发帖人头像也有效。但这但来一个问题：用户头像占位的尺寸不是固定的，如果你在较快速滚屏时随着头像的加载会扩大帖子高度，给人带来视觉上的相当不舒服——帖子不是平滑滚动，而是随着头像的出现一顿一顿的。 其实对头像图片完全没必要使用这个技术：本来头像图片就小并且属于静态文件，无论是在服务器端还是客户端浏览器都有缓存机制使得性能瓶颈不在这儿。性能没多大提升却让用户体验下降，得不偿失。

2、关于X2beta新构架介绍 http://dev.discuz.org/wiki/index.php?title=X2.5%E7%9A%84%E6%96%B0%E7%A8%8B%E5%BA%8F%E6%9E%B6%E6%9E%84 ，对于功能变化不了解不评论，对于程序架构我的感受是：DZ成也mysql败也mysql。
mysql的优点是简单快速，这个“简单和快速”大家都知道，可知道条件是啥吗？那就是数据库容量，表关系结构复杂度和负荷！
如果记录在百万条以下，SQL表连接不超过3个，并且并发负荷不高，那么MyISAM引擎非常的快。再加上mysql安全性不高，所以可以做成绿色安装版一键安装，并且可以设定控制表尺寸（VPS很喜欢这点，DZ后台那个“在线人数控制”参数就是利用这个功能）。所有这些优点的前提总结下来就是“小”，只要数据量小，压力小，网站小，那么DZ就会很快。但只要数据量大了，流量大了，那么对于不支持事务、不支持行锁的MyISAM来说就是苦难的开始：发帖、改帖就会锁住整个threads/posts表阻塞后续INSERT/UPdATE语句，并且阻塞后续所有的SELECT操作。随着表尺寸的增加表锁时间增加，队列将会越来越长。结果是数据库超时、httpserver超时，如果是管理操作那么由于没有事务的保护那么操作结果就不可预料，尤其是涉及到多表多数据的管理操作可能就会发生数据逻辑错误。

DZ开发者无论做如何的优化、修改，都无法改变一个现实：MySQL这个玩具智力低下、体能不足，在大数据量大并发下的严重性能恶化。

• 关联查询(JOIN)尽量拆分为单条查询，不能拆分的放入主表的类中；

数据库是干嘛用的？ 本来该数据库干的事情让应用程序去做，这真的是画蛇添足。一个httpd进程大概占用20M内存，PHP程序不能尽快运行结束不但影响并发同样也耗费资源。如果是php-fpm模式跑的php那502就容易出现了。
只不过MySQL在多表连接时弱智得让人无语的表现让人无法信任它，其子查询性能更不用考虑。真让DZ的开发人员头痛哟～

• post表的优化

问题：

高楼贴的性能问题 limit 187460, 20

方法：

增加position字段记录楼层，修改主键为：PRIMARY KEY (tid, `position`)联合主键，其中position 为auto_increment;

pid字段保留，仍然是auto_increment（单独的一个表），保持唯一，其值在一个单独的表中记录，保留此字段的主要目的是可以让原程序的基本不用做修改;

使用方法：

SELECT * FROM pre_forum_post WHERE tid=424 AND position>=$start AND position<$end ORDER BY position;

搞这么复杂皆因MySQL索引弱智，只有主键索引才能有最佳性能，如果对其他字段索引进行查询性能不高（与MySQL采用的索引组织表结构有关。oracle是同时支持索引组织表和堆表）并且mysql的所谓查询优化器（别人都是查询规划器，这点mysql还是比较老实没敢冒充）对非主键索引的效率判定及使用相当差（基本只使用PK）。

分布部署
媒体X分布式部署.jpg
&#8226; Server1中为所有未分布部署的表，其中每一个表都可以再部署为独立的服务器，例如： common_session表;
&#8226; Server2-Server19均为最小分布部署单位，不可再拆分;
&#8226; 可以将多个Server合并为一个Server，也可并入Server1中，例如：Server11-19可合并为一个 Server;
&#8226; 建议将Server4(member)、Server9(post)、Server10(thread)独立部署

mysql搞的啥读写分离只是因其弱智低能结果被大家当成了优化银弹。你再怎么读写分离，写节点的数据终究要同步到读节点中同样存在瓶颈的。并且如果使用了事务你如何保证读写节点数据的ACID？？
没想到DZ居然还更进一步把数据表都划分服务器部署，看来是准备吊死在myisam这棵树上，不准备支持事务了。不支持事务将来会是许多问题的根源，尤其是积分交易模块部分！
当然说到支持事务的innodb那也是本难念的経：虽然支持事务，但事务不支持DDL操作。诸如X系列强大的分表功能依然不能收到保护。并且最关键的是innodb的SELECT COUNT（*）是扫全表的，速度和pgsql一样极其的慢（这也是mysql vs pgsql中前者比后者的一个对比优势），如果采用那么多半DZ彻底会栽倒～

诸如这些改动、优化都是削足适屐的做法，为了简单弱智的mysql把DZ程序代码越弄越复杂（本来一条多表连接查询可以完成的SQL给切分成多条SQL，虽然关联查询的压力降低了但多次查询本身带来的额外开销也是不可忽视的），维护也越来越麻烦。

至于看到因为管理操作失败，或者其他原因，或者什么原因都没有出现数据库表损坏而需要使用工具修复表的事情，真替这些站长难过。也就mysql这个垃圾数据库才会频繁出现坏表事故。其他任何有名的数据库，无论商用的还是开源的都没这种情况。也许大家对坏表已经习惯麻木觉得正常了，但对于一个敢称呼为“RDBMS”的数据库来说数据表损坏都是大事故都是不可接受的。其他数据库DBA维护人员都在忙着优化SQL索引，而mysql的却忙着修复表。悲哀……

本来postgresql就数据库功能上更适合，性能上也比mysql更强。可惜在win平台上性能不如linux平台，安装部署比mysql麻烦多不太适合广大DZ站长，所有DZ在某个老版本采用过最后也放弃了。

对于尚使用7.2版本站长，其实该版本是有不少坑爹之处可优化的。网上搜索dz7.2+坑爹看看，就不发广告了～

不容易，写了那么多，支持下

技术贴啊 看不懂 不过怎么最后又说到7.2了呢

veshow 发表于 2012-2-12 18:31
技术贴啊 看不懂 不过怎么最后又说到7.2了呢

意思是如果做个小论坛不求花哨功能还是7.2的好，它还有不少可优化提升的地方。
前面是写给DZ开发看的，后面是给站长的（喜欢动手的会有收获的）～

力求继续研发 7.2 感觉7.2 的UI上改进就比较完美了

yangkuan 发表于 2012-2-12 19:18
力求继续研发 7.2 感觉7.2 的UI上改进就比较完美了

X2都有了怎么可能继续研发7.2呢，最多是打点补丁而已

楼主是技术牛人啊

大家能帮我看看我的是什么版本的吗？
演示地址：http://www.mengmao.co

技术帖，我看不民懂。