记标题章节错误,批量更改 某小说章节有600章左右,但是在79章之后的所有标题中的章节序号均发生错误,但是序号是对的,粗略的表结构如下id 标题 序号 1280 第七十九章 标题 80 1281 第八十章 标题 81 ... 也就是说需要把标题中序号都更正过来,稍微构思了一下, 是否可以用replace函数 做正则替换呢...但是查了资料,好像是不行的,于是就采用了下面的方法update txt set title=concat('第',seq,(substring(title,instr(title,'章')) )) where bid=33 and seq>=80;上述语句中, 用了3个mysql 的内置函数 分别是instr(str,substr) 返回字符串substr在字符串str第一次出现的位置(str不包含substr时返回0) substring(str,pos) 返回字符串str的位置pos起的一个子串 concat(str1,str2,...)把参数连成一个长字符串并返回(任何参数是null时返回null)

mysql存储过程&时间累加插入 DELIMITER $$ CREATE DEFINER=`root`@`%` PROCEDURE `cday`( a int ) BEGIN declare i int; set i = 1; while i < a do insert into day_time (ctime) select (ctime+86400) ctime from day_time order by ctime desc limit 1; set i = i +1; end while; END$$ DELIMITER ;上述代码 执行方法为 call cday(10);将往day_time 表插入 9条数据

ffmpeg切割视频 对于一个视频如果我们只需要其中的一部分该怎么办呢？可能的答案有：用视频编辑软件选取我们需要的片段再导出来就好了。是的这样确实可以实现，但是会有几个问题 、1.需要用到专业的软件2.需要重新编码3.时间比较长4.和原画比可能更加模糊。。。那么有没有一种简单而且不损画质而且还快速的方法呢？答案是：有。方法如下：ffmpeg -ss 00:00:05.5 -i 下载/视频文件.flv -vcodec copy -acodec copy -t 00:3:34 视频.mp4 -ss 开始时间 -i 需要切割的视频文件的路径 -vcodec copy 转换后的视频文件和源文件一致 -t 时间（开始时间之后的值 ） 最后 是输出的 文件路径

mysql 中时间怎么进行统计？ 表数据如下日期 通话时间 通话类型 通话号码 2008-09-08 00：30：05 主叫 13212121234 2008-09-07 00：20：35 主叫 13212121234 ×××球总通话时长？可能你会认为这个很简单select sum(通话时间) from table 但是你会得到你所意外的结果sum(通话时间) 5040 ～大概可能是这个结果 What?怎么会是这样的呢对于mySql来说其实际算法是将datetime类型字段值按4位年、2位月、2位日、2位时、2位分、2位秒顺序组成一个数字后再进行累加那么正确的写法呢？SELECT SEC_TO_TIME( SUM( TIME_TO_SEC( `通话时间` ) ) ) AS 总时长 FROM table;

使用Siege对网站做压力测试 sudo siege -c20 -r10 http://www.baidu.com/ -c 指定并发数 -r 指定测试的次数 sudo siege -c20 -t1 http://www.baidu.com/ -t 持续测试 分钟(1/60s) siege -c 20 -r 10 -f url.txt -i -f url.txt 指定url的文件(用回车分割每个URL) -i internet系统，随机发送url -b 请求无需等待 delay=0 -r和-t一般不同时使用更多帮助信息,找linux的男人问一下比如man siege;sudo siege -h结果示意:Transactions: 2 hits # 总共测试次数 Availability: 100.00 % # 成功次数百分比 Elapsed time: 9.02 secs # 总共耗时多少秒 Data transferred: 0.01 MB # 总共数据传输 Response time: 2.73 secs # 等到响应耗时 Transaction rate: 0.22 trans/sec # 平均每秒处理请求数 Throughput: 0.00 MB/sec # 吞吐率 Concurrency: 0.61 # 最高并发 Successful transactions: 9 # 成功的请求数 Failed transactions: 0 # 失败的请求数 Longest transaction: 5.40 Shortest transaction: 0.00