骑虎的康盛，两难的站长，关于Discuz发展的讨论

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

午休有点时间，就随便写写

DZ2.5出了一段时间了，可这官网论坛的bug版块可越来越热闹。神马问题的都有，神奇的是版主的回复往往都是“我这儿测试没问题”。这可就奇怪了，不少问题是很多人发帖都遇到的， 排除站长方面非技术问题（比如设置有误、中毒、网络出问题），总有和技术（程序代码）有关的疑难吧，可为何官方人员测试又正常呢？

康盛的版主可能就没仔细考虑过原因所在。刚才灵光一闪忽然明白了 ～～ 那就是版主测试的系统数据是“逻辑”完整的，而站长们的数据往往是“逻辑”不完整甚至有错误的。所以有缺陷的代码引发的bug无法在版主那儿被触发。这细节说来可就话长了，时间不多，在此简要分析之。

不少站长是从老版本一路升级上来，因为DZ本身代码缺陷以及没使用数据库事务（Transaction,）来保证数据之间参考完整性导致在对数据库进行写入操作（发帖、删帖）时会因为各种原因产生数据逻辑错误。比如删除主题时先把所有回帖删除，待删除主题时出错，这种情况还好办最多是个无回帖的光主题。如果是版主前台删除主题到回收站，程序先把主题打上删除标签，在写入回收站表（7.2下是threadsmod）时出错，这就会产生在后台看到回收站有N个主题，点击进去却没记录的状况。这也好办，如果遇上合并版块、合并/拆分主题(7.2在拆分时代码有bug)、删除用户等大数据量长操作时间的操作时一旦中途出错停止，数据库无法回滚数据（rollback），这问题可就不小了罗。
再加上垃圾的msyql时不时表崩溃等让你来修复，这数据可就一团乱麻了。

这种情况下老系统还能凑合用，一旦升级了新系统。新来方丈这经可就不好念哟：逻辑错误的数据将会被新系统新增的功能、模块所访问使用并产生一系列‘灵异’故障。说灵异是因为这代码在官方那儿可是跑得欢，但到了站长庙里就蔫了～

数据库数据逻辑错误这问题看似简单但不好解决——直接删除错误数据一了百了，但哪些有用哪些无用该如何判断？ 如果要转换有用的错误数据，又该如何重新关联、重建相关环境数据呢？

说到底，这根就在这MySQL上了。大家都知道mysql傻快，但往往不知道为啥快。简而言之就是因为“简单”，程序代码简单，功能也简单——处理个简单SQL查询很快，一旦是多表连接多条件查询，立马现原形，要做结果差集操作？没门，这正是mysql不能被严格成为“关系型数据库”（RDBMS）的原因。
在discuz X系列以前，站长论坛累计的数据量不大，一般就百万条帖子吧。虽然dz代码有缺陷，mysql不给力但还是能跑跑的（忽然想起《活着》中那句‘急了也能跑’，哈哈）。到X推出后现今数据量超千万的站也不会少了，虽然康盛对新版程序构架优化、数据库优化分库上做了不少改进，但这些改进带来的一点提升却被暴增的新功能所吞噬尽，反而因为更加复杂的SQL或者因为服务器分表的多次查询延迟而更加恶化——代码级的优化已经无法环节系统的缓慢。mysql只能接受简单的查询，对于新增的关系复杂的功能多带来的复杂查询条件力不从心。

数据库此时就是整个系统的瓶颈。

即便采用了内存缓存技术（memcache），可总是有数据要写入数据库的，比如session，pv，在线时间等等。myisam一写表就锁表，遇上高流量即便没有发帖系统照样扛不住。你说换支持行锁的innodb引擎吧，可mysql不能再说自己飞快了，一个 SELECT count(*)就能让系统龟速。最坑爹的是才知道innodb的所谓行锁是锁索引，使用也是有条件的：

InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是 使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索 引或普通索引，InnoDB都会使用行锁来对数据加锁。
（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决 定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突 时，别忘了检查SQL的执行计划，以确认是否真正使用了索引

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。

这真难办啊，myisam是快，可是大并发下锁表阻塞严重，还时不时抽风坏表；innodb支持事务（先不谈支持的程度）不坏表吧可速度就慢多了（尤其是对于论坛这种经常要做select count(*)操作的）。这mysql众多引擎，各有特色，可就没一顺手放心的，还是那句话，就一坑爹的要你命3000（不知道的去看周星星的《大内密探零零七》）。
可康盛已经被mysql所捆绑了，构架优化都是针对MySQL的，比如分表到服务器，查询SQL切分连表操作为多个单表查询。要换数据库？还不如重写DZ呢。
现有新增功能已经因为历史数据而产生多多的问题，也让数据库更加疲惫，所以对于站长对新功能的呼声，官方只能忽视了。

骑虎之势的康盛～～

要说这些改进无用是不正确的，可对于普通站长来说如果想要论坛跑得欢，就得考虑如下配置：
1台或以上web服务器，2台或以上数据库服务器，1台或以上附件服务器，再加上可能的多台反向代理服务器（跑nginx反向代理或者vanish图片缓存）……
不带这么玩的吧～ 不说服务器造价，光是IDC托管费用就是普通站长无法负担的

悲摧郁闷的站长……


即便到现在7.2的bug现在依然不少： http://www.oschina.net/question/126398_36342  
X2.5只会更多～

ADD：
对于站长来说，如果自己不懂编程也不愿意花钱找人维护系统，那么只能是跟随DZ的升级而解决bug问题。不过DZX系列从之前的纯论坛转变到社区系统，这并不适合部分站长纯论坛小巧快速的要求。不升级？无法解决bug；升级？功能庞大并且bug也多。是谓两难。