博客园_无线我的无限--角摩网(http://www.joymo.cn)

数组中子序列最大和算法

2011-03-18T04:33:00Z

昨天有同事去别的公司面试，考了这样一道题，说写得不好，问能不能有时间复杂度为数组长度的算法，这个应该不难，写了段代码，执行上应该没错。

int main(int argc, char* argv[])

{

int a[]={10,3,-5,16,90,-100,90,6,-7};

int n =sizeof(a)/sizeof(int);

int max = 0;

int tmpmax = 0;

for(int i=0;i<n;i++)

{

if(tmpmax+a[i]>max)

{

tmpmax = max = tmpmax+a[i];

}

else

{

tmpmax = tmpmax+a[i];

if(tmpmax<0)

tmpmax = 0;

}

cout<<"MaxValue: "<<max<<endl;

return 0;

}

嘿嘿，谁能看出那个数组中和最大的子序列是什么？？

应该是最简单的算法了，在网上搜了下，好些人写得有问题，误人子弟啊。

上面是没有考虑全负的情况，修正如下：

    int a[]={-10,3,9,-16,-90,-100,-90,6,-7};
   int n =sizeof(a)/sizeof(int);

   int max = a[0];
   int tmpmax = 0;

   for(int i=0;i<n;i++)
   {
       if((tmpmax=tmpmax+a[i])>max)
       {
           max = tmpmax;
       }
       else
       {
           if(tmpmax<0)
           {
               if(max<0)
                   if(a[i]>max)
                       max = a[i];
               else
                   tmpmax = 0;
           }

       }
   }

   cout<<"MaxValue: "<<max<<endl;
如果全负实际是做了一遍选择排序。

本文链接

jira 4.2破解安装Linux和windows版

2011-01-27T04:33:00Z

1、配置java环境

（详见在linux下安装java）

2、安装mysql

如果没有安装mysql的话可以快速安装

Mysql 5.1.36 auto-install

按照以上方法即可快速安装

一般我习惯将脚本全部放入/usr/local/src/scripts中

# chmod +x mysql_5.1.36.sh

# ./mysql_5.1.36.sh

如果觉得下载太慢，可以提早去官方网站下好，上传到/usr/local/src/tarbag下

执行完毕没有报错，即可。

3、Jira下载&安装&破解

3.1下载&解压

3.1.1 版本：Atlassian.JIRA.v4.2

(下载地址：http://hotfile.com/get/77389957/4d15a44a/779d520/Atlassian.JIRA.v4.2.Incl.Keygen.and.Patch-iNViSiBLE.rar)

3.1.2 解压步骤：

hotfile大文件解压步骤

将解压后的atlassian-jira-enterprise-4.2.1-b588-standalone.tar.gz上传到服务器

/usr/local/src/tarbag/atlassian/jira目录下(习惯，可根据个人需求更改)

解压到/usr/local/src/software(习惯，可根据个人需求更改)

将atlassian-jira-enterprise-4.2.1-b588-standalone拷贝到/www目录下

建议使用如下路径，比较符合java习惯

/www/atlassian/jira/x.x.x

(x.x.x是版本号，在本文档中是4.2.1)

# cp -rp atlassian-jira-enterprise-4.2.1-b588-standalon /www/atlassian/jira/4.2.1

3.2安装

3.2.1 在MySql中专将JIRA数据库

进入mysql输入

mysql>create database jira character set utf8;

mysql>grant all on jira.* to 'jira'@'localhost' identified by 'jira';

mysql>grant all on jira.* to 'jira'@'%' identified by 'jira';

3.2.2安装JIRA

Jira的安装路径

$Install_Jira=/www/atlassian/jira/4.2.1

创建jira.home文件夹

# cd /www/atlassian/jira/

# mkdir jira_home

# useradd jira

# passwd jira

# chown -R jira:jira /www/atlassian/jira/jira_home

3.2.3修改Jira配置文件

修改$Install_Jira/atlassian-jira/WEB-INF/classes/jira-application.properties 文件

找到jira.home =

修改为jira.home =/www/atlassian/jira/jira_home 绝对路径

注：jira.home文件夹不可以设置为jira根目录及其子目录，关于这个目录做什么用，我也不清楚，估计是jira程序放临时文件用的吧。如果启动失败会在这个目录下生成一个.jira.lock的文件，重启前切记要删掉，否则无法重启。

修改$Install_Jira/conf/server.xml文件

修改成如下几项

username="jira"

password="jira"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost:3306/jira?autoReconnect=true&useUnicode=true&characterEncoding=UTF8"

删除以下两行

minEvictableIdleTimeMillis= "4000"

timeBetweenEvictionRunsMillis="5000"

修改$Install_Jira/atlassian-jira/WEB_INF/classes/entityengine.xml文件

将其中的hsql改成mysql 数据库类型

<datasource name= "defaultDS" field-type-name= "hsql"

改为：

<datasource name="defaultDS" field-type-name= "mysql"

删除 schema-name="PUBLIC"

----------------------------------------------------------------以下windows版

从下面下载rar文件，在widnows下安装即可，破解过程linux和windws同下

http://download.csdn.net/source/2775261

http://download.csdn.net/source/2775315

http://download.csdn.net/source/2775261

4、破解

4.1 方法1

1. 下载破解补丁(jira_crack.zip)(jira4.2 破解补丁)

下载地址：jiar4.2.1破解文件及破解程序

2.用破解补丁中的JiraLicenseStoreImpl.class文件覆盖/www/atlassian/jira/atlassian-jira/WEB_INF/classes/com/atlassian/jira/license/JiraLicenseStoreImpl.class文件

3. 用破解补丁中的Version2LicenseDecoder.class文件覆盖/www/atlassian/jira/atlassian-jira/WEB_INF/lib/atlassian-extras-2.2.2.jar包中的atlassian-extras-2.2.2.jar\com\atlassian\extras\decoder\v2\Version2LicenseDecoder.class文件

注：jar包可以用WinRAR打开，并可以采用拖拽的方式覆盖文件

4.运行JIRA服务

$Install_Jira/bin/startup.sh

5.WEB 配置 JIRA

在web浏览器中输入http://IP:8080进入安装配置页面

官方文档

http://www.atlassian.com/software/jira/docs/v3.13/setup.html

6.在注册码输入框处输入以下内容：

Description=JIRA\: longmaster

CreationDate=2010-02-22

ContactName=tonyty163@766.com

jira.LicenseEdition=ENTERPRISE

ContactEMail=tonyty163@766.com

Evaluation=false

jira.LicenseTypeName=COMMERCIAL

jira.active=true

licenseVersion=2

MaintenanceExpiryDate=2099-10-24

Organisation=zzh

jira.NumberOfUsers=-1

ServerID=BVGH-1XEQ-1TVR-OO3O

LicenseID=LID

LicenseExpiryDate=2099-10-24

PurchaseDate=2010-10-25

（注意：以上的ServerID要根据license输入框上面的ServerID进行更改）

MaintenanceExpiryDate和LicenseExpiryDate可控制jira的到期时间

7.现行的破解方法如果不行，可下载解码器进行破解

Atlassian.JIRA.v4.2破解程序和注册机（2010年10月22日更新）

（下载地址http://d.download.csdn.net/down/2775357/vb_dot_net）

随便找个装java的windows，运行下keygen.bat，输入相关信息，得到注册码

或者找到一个带图形界面的linux，运行下keygen.sh，同样得到注册码即可

4.3 方法2(推荐，不需要额外下载破解程序软件)

借鉴iNViSiBLE破解&补丁程序使用教程

安装即可

5、Jira汉化

网上下载的汉化包，目前能下载到的我搜了下，大概是4.0的

jiar4.2.1-插件汉化

由于jira新版本的汉化大部分都不完全，所以这里要用我给的包，那个是公司同事齐心协力汉化了很久后的杰作，经测试在4.2版本使用一切正常，极少数地方没有汉化。

汉化流程是：

1.先停止jira

# $Install_Jira/bin/shutdown.sh

2.把language_zh_CN.jar拷贝至，$Install_Jira/atlassian-jira/WEB-INF/lib下，由于目录下有同名，出于安全，应该先备份老的，但是一定不要备份到生产环境的目录下，因为java是不认文件后缀，只认目录下文件的，备份最好是另外备份一个目录；
3.启动jira，观察日志，如果没报错，就应该汉化完成了

4.进去你的jira查看成果吧。

http://IP:8080

6、Jira自启动脚本

（详见Jira自启动脚本）

7、Jira插件安装

7.1 GreenHopper插件安装

（详见Jira插件GreenHopper安装&破解）

8、排错

8.1 启动后在面板右下角出现的数据库警告

出现如下错误

WARNING: You are using MySQL but do not have a validation query configured. Because of MySQL connection timeouts, this situation can cause data corruption in JIRA. For more information please see this bug report.

以下是节选自官方解决方案的方法

http://confluence.atlassian.com/display/JIRA/Surviving+Connection+Closures

Setting the validationQuery parameter

In your application server, where the JDBC DataSource is configured, a parameter needs to be added to tell the Connection Pool to use a validation query (determined above) to validate connections.

JIRA Standalone (after version 3.2) or JIRA EAR/WAR on Tomcat 5.5 and Tomcat 6.0

If you are using JIRA Standalone, edit conf/server.xml
If you are using JIRA EAR/WAR on Tomcat 5.5 or Tomcat 6.0, edit conf/Catalina/localhost/jira.xml

Locate the section where the 'jdbc/JiraDS' DataSource is set up, and add the following:

· If you are using MySQL or MS SQL Server, add validationQuery="select 1"

· If you are using Oracle, add validationQuery="select 1 from dual"

· If you are using Postgres, add validationQuery="select version();"

For example (for MySQL):

<Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost/jiradb?useUnicode=true&characterEncoding=UTF8"

username="jirauser"

password="jirapassword"

maxActive="20"

validationQuery="select 1" />

按照以上文档所写，就是在 conf/server.xml或者新版本中的conf/Catalina/localhost/jira.xml添加以上蓝色内容即可解。只要按照文档做下来的话，一般只要加入validationQuery="select 1"这段即可。

本文出自 “滕赖赖的技术小窝” 博客，转载请与作者联系！

本文链接

[z]windows下Svn服务器之必须提交修改注释篇

2011-01-17T08:04:00Z

1. 强制添加注释信息

找到Respositories目录下对应项目里的hooks目录下建立pre-commit.bat文件，复制如下内容：

@echo off

set SVNLOOK="C:\Program Files\VisualSVN\bin\svnlook.exe"

setlocal

set REPOS=%1

set TXN=%2

rem check that logmessage contains at least 10 characters

%SVNLOOK% log "%REPOS%" -t "%TXN%" | findstr ".........." > nul

if %errorlevel% gtr 0 goto err

exit 0

:err

echo Empty log message not allowed. Commit aborted! 1>&2

exit 1

2. 允许用户修改注释信息

找到Respositories目录下对应项目里的hooks目录下建立pre-revpos-change.bat，复制如下内容：

@ECHO OFF
set repos=%1
set rev=%2
set user=%3
set propname=%4
set action=%5

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Only allow changes to svn:log. The author, date and other revision
:: properties cannot be changed
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if /I not '%propname%'=='svn:log' goto ERROR_PROPNAME

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Only allow modifications to svn:log (no addition/overwrite or deletion)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if /I not '%action%'=='M' goto ERROR_ACTION

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Make sure that the new svn:log message contains some text.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
set bIsEmpty=true
for /f "tokens=*" %%g in ('find /V ""') do (
set bIsEmpty=false
)
if '%bIsEmpty%'=='true' goto ERROR_EMPTY

goto :eof

:ERROR_EMPTY
echo Empty svn:log properties are not allowed. >&2
goto ERROR_EXIT

:ERROR_PROPNAME
echo Only changes to svn:log revision properties are allowed. >&2
goto ERROR_EXIT

:ERROR_ACTION
echo Only modifications to svn:log revision properties are allowed. >&2
goto ERROR_EXIT

:ERROR_EXIT
exit /b 1

本文链接

利用角摩电子书控件开发电子书生成网站源码，支持手机、PC和IPAD手持电脑的电子书格式

2011-01-07T11:25:00Z

对原有的电子书生成代码进行了分离，做成dll供软件和网站使用。

适合C#开发的各类阅读软件使用，对于各类资讯、博客、微博等信息类网站也非常适合使用，让用户能方便地将自己喜欢的内容定制成电子书方便地与朋友分享，或者放到手机中随时随地阅读。

asp.net调用源码下载：（注意阅读使用必读）

源码下载(网站版)

在线制作演示：http://www.joymo.cn/bookonline/

目前支持jar手机电子书，epub，umd，chm，pdf等5种电子书格式的生成！
自动拆分大的文本文件为多个合适的章节！
自动识别不同编码格式文本内容！
Jar格式支持书签，搜索，进度条提示，换字体，换背景色功能！

本文链接

角摩网官方论坛蛙铺网开放

2010-09-25T05:50:00Z

蛙铺网作为角摩网的官方论坛采用discuz1.5X，主要面向对角摩软件的答疑和合作，以及ipad和android的交流论坛。基于.cn域名的严重不靠谱，蛙铺网采用的域名http://www.iiwap.net，以后角摩的业务会慢慢调整到蛙铺网。

蛙铺网会继续加强手机电子书在线制作功能，未来会添加网页直接生成epub电子书。

本文链接

新型的大型bbs架构（squid+nginx）

2010-09-16T13:15:00Z

这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点：

1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。

2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。

3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。

首先看图，这个图比较大：

这个架构的特点和一些流程的说明：

1、主域名和图片域名分离

域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。

2、使用LVS作为前端、二级代理和数据库的访问入口

使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。

3、使用nginx+squid作为最前端的缓存组合

在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用 purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的时候，purge将成为一个巨大的压力。

所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到对应的机器就可以了。

可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。

nginx作为前端，另有的好处：

1/使用nginx的日志统计点击量非常方便
2/nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片

4、基于nginx的中层代理

nginx中层代理的优势，在：

nginx和squid配合搭建的web服务器前端系统

这篇文章中有解释。

在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端 app_server的硬盘容量的压力，但是如果使用到url_hash的话，那做容错就相对麻烦了。所以建议不要采用生成静态页的方式，后端的压力一般不会非常的大，所以没有必要生成静态页。假如前端squid的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。

5、基于LVS的数据库双机热备

在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的mysql主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳定，一般不会随着访问量上升而提高过快，估计目前一台64位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题。使用双机热备的方案，出现故障时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。

当然，数据库的优化还是要细心做的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好很多。

6、图片服务器

图片服务器我在这个架构中没有特别详细的介绍，在大型的bbs系统下，图片常常会出现容灾现象——图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。

7、简单的点击量统计办法

1/使用js的script标签访问另一（台）组服务器的空文件，然后定期向数据库更新
2/在前端的nginx上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库

本文链接

mysql性能的检查和调优方法

2010-09-16T13:08:00Z

我一直是使用mysql这个数据库软件，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能：

1、索引没有建好；
2、sql写法过于复杂；
3、配置错误；
4、机器实在负荷不了；

1、索引没有建好

如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。

在linux下执行

/usr/local/mysql/bin/mysql -hlocalhost -uroot -p

输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。

看看当前的运行情况

show full processlist

可以多运行几次

这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息

在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题

如果出现了性能问题，则可以进行分析：

1、是不是有sql语句卡住了？

这是出现比较多的情况，如果数据库是采用myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。

查看processlist里的time这一项，看看有没有执行时间很长的语句，要留意这些语句。

2、大量相同的sql语句正在执行

如果出现这种情况，则有可能是该sql语句执行的效率低下，同样要留意这些语句。

然后把你所怀疑的语句统统集合一下，用desc（explain）来检查这些语句。

首先看看一个正常的desc输出：

mysql> desc select * from imgs where imgid=1651768337;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|   1 | SIMPLE       | imgs   | const | PRIMARY       | PRIMARY | 8       | const |     1 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

注意key、rows和Extra这三项，这条语句返回的结果说明了该sql会使用PRIMARY主键索引来查询，结果集数量为1条，Extra没有显示，证明没有用到排序或其他操作。由此结果可以推断，mysql会从索引中查询imgid=1651768337这条记录，然后再到真实表中取出所有字段，是很简单的操作。

key是指明当前sql会使用的索引，mysql执行一条简单语句时只能使用到一条索引，注意这个限制；rows是返回的结果集大小，结果集就是使用该索引进行一次搜索的所有匹配结果；Extra一般会显示查询和排序的方式，。

如果没有使用到key，或者rows很大而用到了filesort排序，一般都会影响到效率，例如：

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key   | key_len | ref   | rows   | Extra                       |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
|   1 | SIMPLE       | imgs   | ALL   | NULL           | NULL | NULL     | NULL | 12506 | Using where; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)

这条sql结果集会有12506条，用到了filesort，所以执行起来会非常消耗效率的。这时mysql执行时会把整个表扫描一遍，一条一条去找到匹配userid="7mini"的记录，然后还要对这些记录的clicks进行一次排序，效率可想而知。真实执行时如果发现还比较快的话，那是因为服务器内存还足够将12506条比较短小的记录全部读入内存，所以还比较快，但是并发多起来或者表大起来的话，效率问题就严重了。

这时我把userid加入索引：

create index userid on imgs (userid);

然后再检查：

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|   1 | SIMPLE       | imgs   | ref   | userid         | userid | 51       | const |     8 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

嗯，这时可以看到mysql使用了userid这个索引搜索了，用userid索引一次搜索后，结果集有8条。然后虽然使用了filesort一条一条排序，但是因为结果集只有区区8条，效率问题得以缓解。

但是，如果我用别的userid查询，结果又会有所不同：

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|   1 | SIMPLE       | imgs   | ref   | userid         | userid | 51       | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这个结果和userid="7mini"的结果基本相同，但是mysql用userid索引一次搜索后结果集的大小达到2944条，这2944条记录都会加入内存进行filesort，效率比起7mini那次来说就差很多了。这时可以有两种办法可以解决，第一种办法是再加一个索引和判断条件，因为我只需要根据点击量取最大的10条数据，所以有很多数据我根本不需要加进来排序，比如点击量小于10的，这些数据可能占了很大部分。

我对clicks加一个索引，然后加入一个where条件再查询：

create index clicks on imgs(clicks);

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|   1 | SIMPLE       | imgs   | ref   | userid,clicks | userid | 51       | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这时可以看到possible_keys变成了userid,clicks，possible_keys是可以匹配的所有索引，mysql会从 possible_keys中自己判断并取用其中一个索引来执行语句，值得注意的是，mysql取用的这个索引未必是最优化的。这次查询mysql还是使用userid这个索引来查询的，并没有按照我的意愿，所以结果还是没有什么变化。改一下sql加上use index强制mysql使用clicks索引：

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>10 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
|   1 | SIMPLE       | imgs   | range | clicks         | clicks | 4       | NULL | 5455 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

这时mysql用到了clicks索引进行查询，但是结果集比userid还要大！看来还要再进行限制：

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>1000 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
|   1 | SIMPLE       | imgs   | range | clicks         | clicks | 4       | NULL |   312 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

加到1000的时候结果集变成了312条，排序效率应该是可以接受。

不过，采用换索引这种优化方式需要取一个采样点，比如这个例子中的1000这个数字，这样，对userid的每个数值，都要去找一个采样点，这样对程序来说是很难办的。如果按1000取样的话，那么userid='7mini'这个例子中，取到的结果将不会是8条，而是2条，给用户造成了困惑。

当然还有另一种办法，加入双索引：

create index userid_clicks on imgs (userid, clicks)

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys         | key           | key_len | ref   | rows | Extra       |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
|   1 | SIMPLE       | imgs   | ref   | userid,userid_clicks | userid_clicks | 51       | const | 2944 | Using where |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
1 row in set (0.00 sec)

这时可以看到，结果集还是2944条，但是Extra中的filesort不见了。这时mysql使用userid_clicks这个索引去查询，这不但能快速查询到userid="admin"的所有记录，并且结果是根据clicks排好序的！所以不用再把这个结果集读入内存一条一条排序了，效率上会高很多。

但是用多字段索引这种方式有个问题，如果查询的sql种类很多的话，就得好好规划一下了，否则索引会建得非常多，不但会影响到数据insert和update的效率，而且数据表也容易损坏。

以上是对索引优化的办法，因为原因可能会比较复杂，所以写得比较的长，一般好好优化了索引之后，mysql的效率会提升n个档次，从而也不需要考虑增加机器来解决问题了。

但是，mysql甚至所有数据库，可能都不好解决limit的问题。在mysql中，limit 0,10只要索引合适，是没有问题的，但是limit 100000,10就会很慢了，因为mysql会扫描排好序的结果，然后找到100000这个点，取出10条返回。要找到100000这个点，就要扫描 100000条记录，这个循环是比较耗时的。不知道会不会有什么好的算法可以优化这个扫描引擎，我冥思苦想也想不出有什么好办法。对于limit，目前直至比较久远的将来，我想只能通过业务、程序和数据表的规划来优化，我想到的这些优化办法也都还没有一个是万全之策，往后再讨论。

2、sql写法过于复杂

sql写法假如用到一些特殊的功能，比如groupby、或者多表联合查询的话，mysql用到什么方式来查询也可以用desc来分析，我这边用复杂sql的情况还不算多，所以不常分析，暂时就没有好的建议。

3、配置错误

配置里主要参数是key_buffer、sort_buffer_size/myisam_sort_buffer_size，这两个参数意思是：

key_buffer=128M：全部表的索引都会尽可能放在这块内存区域内，索引比较大的话就开稍大点都可以，我一般设为128M，有个好的建议是把很少用到并且比较大的表想办法移到别的地方去，这样可以显著减少mysql的内存占用。
sort_buffer_size=1M：单个线程使用的用于排序的内存，查询结果集都会放进这内存里，如果比较小，mysql会多放几次，所以稍微开大一点就可以了，重要是优化好索引和查询语句，让他们不要生成太大的结果集。

另外一些配置：
thread_concurrency=8：这个配置标配=cpu数量x2
interactive_timeout=30
wait_timeout=30：这两个配置使用10-30秒就可以了，这样会尽快地释放内存资源，注意：一直在使用的连接是不会断掉的，这个配置只是断掉了长时间不动的连接。
query_cache：这个功能不要使用，现在很多人看到cache这几个字母就像看到了宝贝，这是不唯物主义的。mysql的query_cache 在每次表数据有变化的时候都会重新清理连至该表的所有缓存，如果更新比较频繁，query_cache不但帮不上忙，而且还会对效率影响很大。这个参数只适合只读型的数据库，如果非要用，也只能用query_cache_type=2自行用SQL_CACHE指定一些sql进行缓存。
max_connections：默认为100，一般情况下是足够用的，但是一般要开大一点，开到400-600就可以了，能超过600的话一般就有效率问题，得另找对策，光靠增加这个数字不是办法。

其它配置可以按默认就可以了，个人觉得问题还不是那么的大，提醒一下：1、配置虽然很重要，但是在绝大部分情况下都不是效率问题的罪魁祸首。2、mysql是一个数据库，对于数据库最重要考究的不应是效率，而是稳定性和数据准确性。

4、机器实在负荷不了

如果做了以上调整，服务器还是不能承受，那就只能通过架构级调整来优化了。

1、mysql同步。

通过mysql同步功能将数据同步到数台从数据库，由主数据库写入，从数据库提供读取。

我个人不是那么乐意使用mysql同步，因为这个办法会增加程序的复杂性，并常常会引起数据方面的错误。在高负荷的服务中，死机了还可以快速重启，但数据错误的话要恢复就比较麻烦。

2、加入缓存

加入缓存之后，就可以解决并发的问题，效果很明显。如果是实时系统，可以考虑用刷新缓存方式使缓存保持最新。

在前端加入squid的架构比较提倡使用，在命中率比较高的应用中，基本上可以解决问题。

如果是在程序逻辑层里面进行缓存，会增加很多复杂性，问题会比较多而且难解决，不建议在这一层面进行调整。

3、程序架构调整，支持同时连接多个数据库

如果web加入缓存后问题还是比较严重，只能通过程序架构调整，把应用拆散，用多台的机器同时提供服务。

如果拆散的话，对业务是有少许影响，如果业务当中有部分功能必须使用所有的数据，可以用一个完整库+n个分散库这样的架构，每次修改都在完整库和分散库各操作一次，或定期整理完整库。

当然，还有一种最笨的，把数据库整个完完整整的做拷贝，然后程序每次都把完整的sql在这些库执行一遍，访问时轮询访问，我认为这样要比mysql同步的方式安全。

4、使用 mysql proxy 代理

mysql proxy 可以通过代理把数据库中的各个表分散到数台服务器，但是它的问题是没有能解决热门表的问题，如果热门内容散在多个表中，用这个办法是比较轻松就能解决问题。

我没有用过这个软件也没有认真查过，不过我对它的功能有一点点怀疑，就是它怎么实现多个表之间的联合查询？如果能实现，那么效率如何呢？

5、使用memcachedb

数据库换用支持mysql的memcachedb，是可以一试的想法，从memcachedb的实现方式和层面来看对数据没有什么影响，不会对用户有什么困扰。

为我现在因为数据库方面问题不多，没有试验过这个玩意。不过，只要它支持mysql的大部分主要的语法，而且本身稳定，可用性是无需置疑的。

本文链接

做了个绿色小巧的jar电子书生成制作工具

2010-09-14T03:43:00Z

根据一些网友对jar电子书制作的需求，专门改装了一个小巧的jar生成工具。只有115K，打开rar就可以使用！

1.自动识别GBK、UTF_8和Unicode各种txt文件；
2.支持目录、单个文件、多文件拖入以及直接添加内容的方式；
3.自动对大尺寸内容进行拆分，拆分的内容大小为150K，拆分不会产生乱码；
4.支持目前市面绝大多数手机；
5.自动定位生成的Jar文件；
6.不需要java环境支持；
7.支持中文文件名。
8.直接将UMD格式转化为JAR。图片格式的UMD文件，会将图片提取到软件所在的目录。

本文链接

jar共存制作器（网站版）开发完成

2010-08-08T06:13:00Z

为智能手机网站提供实时jar共存软件的生成制作！

使用非常方便

1）通过软件配置好相关目录后，按保存，生成asp源代码，上传到网站任意目录；

2）提供本地jar、远程jar和下拉框选择三种模式的制作方式，可以任意选择组合。

下载：http://www.joymo.cn/upfiles/iiwap.net-jar.rar

本文链接

joymobiler V2.7发布，支持pdf文档的生成

2010-07-13T14:48:00Z

采用pdflib控件，生成速度相当快。

支持打开zip里的文件。

界面如下

本文链接