一个程序猿

　　GUID： 即Globally Unique Identifier（全球唯一标识符） 也称作 UUID(Universally Unique IDentifier) 。 GUID是一个通过特定算法产生的二进制长度为128位的数字标识符，用于指示产品的唯一性。GUID 主要用于在拥有多个节点、多台计算机的网络或系统中，分配必须具有唯一性的标识符。
　　在 Windows 平台上，GUID 广泛应用于微软的产品中，用于标识如如注册表项、类及接口标识、数据库、系统目录等对象。

php中并没有标准的guid，只是有个函数 uniqid() 生成唯一id。而在mysql中有函数生成guid：SELECT UUID()

其实已经有一个成形的mysql json编码的模块 http://www.mysqludf.org/lib_mysqludf_json/index.php

不过我们在使用的过程中，发现这个函数有版本兼容的问题，后看代码，发现它的json加密规则比较麻烦，没拆出来分析，就自己使用一个json类 http://sourceforge.net/projects/cjson/ 重写了一遍json_object函数。

目前在mysql-5.0.22版本上使用基本没问题，但在mysql5.5以上版本会有问题，udf接口格式好像有了变化。

mysql-5.0.22版本给出的例子是c++的代码。使用了extern语法，为了兼容gcc的语法。而我实际使用纯C环境，就抛弃了extern的语法。

udf_json源码下载

编译完成，复制so文件至公共库，然后执行以下语句：

使用 ：

PHP调用：

结果显示：

array(3) {
["id"]=>
int(2)
["intval"]=>
int(43324)
["value"]=>
string(10) “fdsfdsfdsa”
}
array(3) {
["id"]=>
int(5)
["intval"]=>
int(432432432)
["value"]=>
string(10) “fdsafdsasa”
}

mysql5.5.8对于守旧的人绝对是一种惨无人道的蹂躏。

我开始用mysql5.5.8了，被忽悠得天花乱坠，说性能提升，说主从同步迅速……

不过我是专用udf功能的，因为我常用的mysql稳定版本5.0.22官方说有点小bug，使用udf有点问题，被迫升级了5.5.8版本。

mysql5.5.8抛弃了我们钟爱的configure，而次用了cmake。

当然你要先安装cmake http://www.cmake.org/files/v2.8/cmake-2.8.3.tar.gz

cmake安装简单，tar后make && make install 搞定。

mysql5.5.8到官网下载 http://dev.mysql.com/downloads/mirror.php?id=399302#mirrors

tar出来，就找不到configure了，不过官方提供了高仿configure的转换脚本，不过神马都是浮云，自己折腾脚本吧

然后make && make install就行。

剩下的事情就跟老版本的一样了，不过我编译的时候没有成功安装 mysql_install_db 脚本，自己写了一个，也算成功完成任务了。


#include
#include
#include “mysql.h”

int main(int argc, char **argv)
{
MYSQL mysql, *sock;
MYSQL_RES *res;
MYSQL_FIELD *fd;
MYSQL_ROW row;
char sql[160];
char host[20];
char user[20];
char pass[20];
char data[20];
int i;
if(argc!=6)
{
fprintf(stderr, “Please input you host, username, password, dbname, sql\n\n”);
exit(0);
}
sprintf(host, argv[1]);
sprintf(user, argv[2]);
sprintf(pass, argv[3]);
sprintf(data, argv[4]);
sprintf(sql, argv[5]);
mysql_init(&mysql);
if(!(sock=mysql_real_connect(&mysql, host, user, pass, data, 0, NULL, 0)))
{
fprintf(stderr, “Can’t connect to engine!\n%s\n”, mysql_error(&mysql));
perror(”");
exit(0);
}
if(mysql_query(sock, sql))
{
fprintf(stderr, “Query failed (%s)\n”, mysql_error(sock));
exit(1);
}
if(!(res=mysql_store_result(sock)))
{
fprintf(stderr, “Couldn`t get result from %s\n”, mysql_error(sock));
exit(1);
}
printf(”number of fields returned:%d\n”, mysql_num_fields(res));
while(row=mysql_fetch_row(res))
{
for(i=0;i {
printf("%d:%s ",i,row[i]);
}
printf("\r\n");
}
mysql_free_result(res);
mysql_close(sock);
exit(0);
return 0;
}

编译参数：gcc mysql.c -o mysql -I /usr/include/mysql -L /lib/mysql -lmysqlclient

今天一天没干别的，没写程序，没玩游戏，除了中午参加公司的一个吹气球比赛得了第一，获得“**公司第一吹”的称号。

一天都在考虑使用完全开源的方案来解决dz sessions表的性能问题。中午大脑极度紧张，以至于撞在关兄的工位，工位几近散架。

在轻度震荡中想到一个优化方案，就是分离sessions表的一些功能，把sessions会话和统计功能分离，并且统计使用异步提交。

这样，如果sessions会话生存期10分钟的量计算，20万人同时在线，sessions会话存memcached，而统计只用少量字段在独立的表中。因为php的sessions操作速度高，而统计信息调用并不是非常频繁，并且查找也是简单的int型查询，速度快，并且也进行memcached缓存。

下午吴同学详细讲述了我们的统计系统的负载和数据量，在大量实际应用的基础上，我的方案应该能很好的实施。

这样算来，连接瓶颈跟存储瓶颈似乎都能解决。明天集中时间实现这个方案。

最近一直在寻找一个开源的方案来解决discuz的性能瓶颈。在做完几个关键表的分表后，sessions表又成了最大的瓶颈。因为页面每次刷新，至少两个sql语句在session表上，究其原因，session表的最大作用在于对用户行为的统计。

曾经尝试过使用php的session，不过支持phpsession的几个sever都不支持条件查询，除非是遍历匹配。这样也不能起到提高性能的作用。

在以上条件下，我寻找了两套方案：ttserver mongodb。

在session表100w数据的测试下，得出以下数据：

连接测试-只测试连接释放
tt:40.0904033184
mysqldb:0.0669066905975

mongodb:226.840053558
mysqldb:0.154407262802

经过一万次的连接测试，同一个脚本中，
ttserver连接耗时 40.09 秒，而mysql连接耗时0.07秒 linux下测试
mongodb 连接耗时 226.8 秒，而mysql连接耗时0.15秒 linux下测试

但是在500次的查询测试中，同一个脚本中，主键查询和索引优化后的复杂查询
mongodb 查询耗时 0.021 秒
mysql 查询耗时 0.123 秒

可以看出，tt和mongo两个功能上完全支持此表优化的数据库，在连接性能上远不如mysql，而web为频繁连接中断的服务，显然并不适合做这项功能。

继续寻找支持此功能的开源方案，欢迎大家提供线索。

最近一直在琢磨discuz的优化，想出一些数据缓存的策略：

index.php 部分数据已经进行了缓存，但需要全部缓存，只有当 页面刷新数/更新时间 >>>> 发帖数/更新时间 ，则有必要做此缓存，此处缓存更新最为频繁，适合做内存缓存，但 更新时间不宜太久，此时间根据首页更新频度确定。

forumdisplay.php 更新频繁，优化策略同上，只是更新频度略低于首页。

viewthread.php 回复更新频繁，内容更新频度低，适合做硬盘缓存。但分页部分不可做缓存，否则……

space.php 更新不频繁，适合做硬盘缓存。

faq.php 做个静态即可。

以上分析只是根据平时维护总结，临时脑子一蹦，未作具体分析，欢迎广大站长讨论试用。版权所有，欢迎盗版。

用phpmyadmin写触发器的朋友，不知道有没有碰见这个问题：用pma导出的语句，死活倒不进去，mysqldump导出的，也不能用pma倒入。

反正问题多多，很令人头疼。

今天再次碰到这个问题后，偶然发现个问题，就是sql输入框下的一个小的内容：语句定界符。

平时导出sql，语句定界符默认是分号，而编辑触发器的时候，是两个斜杠//。

蹊跷就在这里，导入的时候使用的定界符必须跟倒出时候的定界符保持一致，否则就会出现错误。

问题发现后，老王是相当的高兴啊。

discuz论坛在国内非常流行，用户众多。优秀的用户体验和超强的负载，也赢得了众多的好评。

但discuz毕竟是为中小型网站设计，很容易达到性能的瓶颈。在最近对discuz的改造和表结构的分析，做了以下的探讨，来提升论坛的性能。

第一步，当然就是分表。
技术实力不太强的用户（严重依赖mysql的用户），分表是最直接的做法（当然，有些功能会损失）。

分析一个运营两年的discuz数据库，库表大概是十几个G左右，posts数据表已经几个千万。

首先可以拆分的，就是post表了。根据情况，post表可以分10张，百张，规则可以哈希，也可以阶段自增（分表主键使用tid（帖子id））。分完表，可以看到一排post_**的表，每个表的数据量降到百万以下，速度就无太大影响。

第二个可以拆分的，是threads表，此表分表，可以水平分割方式水平的分割，可以根据论坛版块id进行分表，这样可以使每个表的数据量减小，但这样也损失了一个功能：全站标题检索。

通过以上两个表的改造论坛的承载能力能迅速见长。

底下会讨论高级优化改造得方法，且听下次分解。

mysql没有一个像mssql的客户端去管理，所以有了PHPMYADMIN，管理mysql不再单纯依靠命令行，但PHPMYADMIN似乎不是那么万能，偶尔也会耍耍版本细节的脾气。

最近使用mysql触发器，不想使用命令行编辑，但phpmyadmin调试缺比较麻烦，原来想的是先建立一个空的触发器，然后修改，后来发现修改迁移问题多的要死，在老王同学的帮助下，经过几个晚上努力，整理出一些规律。

调试的时候，可以在空的触发器上逐条增加语句，一点一点调试，这样很容易定位问题，迅速修改。

迁移的时候，不能直接编辑触发器拷贝里边的代码，我用的phpmyadmin是2.11.9*版本的，生成的代码虽然他自己认，但一迁移就出了问题，我还没去阅读PHPMYADMIN的代码，不知道代码如何产生，但begin end里的内容大致相同，不同的是两头的辅助语句。

两头的内容跟版本密切相关，用mysqldump导出的语句做模板，把过程添加到里边，基本就没什么问题了。

不同版本的语法稍有出入，没有详细总结，总之掌握了调试的方法，解决问题速度就会提升。

使用触发器后，原来十几次的交互，一次就可以解决。我尝试了下出发器和存储过程，发现开发成本都差不多，复杂度也是类似的，所以没有用存储过程。