手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2024年09月的文章

MYSQL 存储过程

 说实话,关于存储过程的博客还真的不多,有几个是值得看一下的

1、官方;http://dev.mysql.com/doc/refman/5.1/zh/stored-procedures.html

2、http://www.netingcn.com/tag/%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B

3、http://blog.why100000.com/?p=711

也发现,如果不做复杂查询,存储过程对我来说几乎没有,本来是想解决查找GEO相关的信息的,但发现这样的SQL:

SQL代码
  1.  SELECT userid,lat,lng,gender,  
  2.   ( 6371 * acos( cos( radians(31.000700) ) * cos( radians( lat ) ) * cos( radians( lng ) - radians(120.000099) ) + sin( radians(31.000700) ) * sin( radians( lat ) ) ) ) AS distance  
  3. FROM `user_geo` WHERE last_activity_time > '2013-03-11 00:00:00'    
  4. ORDER BY distance ASC limit 100  

这其中的复杂度就在于distance每次都要计算,所以我尝试换成了存储过程:

SQL代码
  1. DROP PROCEDURE IF EXISTS search_around_user;  
  2. DELIMITER //  
  3. CREATE PROCEDURE search_around_user  
  4. (  
  5.     s_lat float(10,6),  
  6.     s_lng float(10,6),  
  7.     s_last_act datetime,  
  8.     s_gender tinyint,  
  9.     s_number tinyint,  
  10.     s_page tinyint  
  11. )  
  12. LABEL_PROC:  
  13. BEGIN  
  14.     if s_number <= 1 then  
  15.         set s_number = 20;  
  16.     end if;  
  17.     if s_page <= 0 then  
  18.         set s_page = 0;  
  19.     end if;  
  20.     if s_gender <= 0 then  
  21.         set @genderQuery = "";  
  22.     else  
  23.         set @genderQuery = concat(" and gender = " , s_gender , " ");  
  24.     end if;  
  25.     set @limitQuery = concat("LIMIT " , s_page * s_number , " , " , s_number , " ");  
  26.   
  27.     set @strsql =  CONCAT("select userid, ",  
  28.         "( 6371 * acos( cos( radians(",s_lat,") ) * cos( radians( lat ) ) * cos( radians( lng ) - radians( ",s_lng," ) ) ",  
  29.         "+ sin( radians( ",s_lat," ) ) * sin( radians( lat ) ) ) ) AS distance ",  
  30.         " FROM user_geo where last_activity_time >= '", s_last_act , "' " , @genderQuery ,  " ORDER BY distance " , @limitQuery) ;  
  31.   
  32.     prepare stmtsql from @strsql;  
  33.     execute stmtsql;  
  34.       
  35.   
  36. END LABEL_PROC;  
  37. //  
  38. DELIMITER ;  

然后再次调用:

SQL代码
  1. call search_around_user(31.000700,120.000099,'2013-03-11 00:00:00',0,20,0)  

所耗费的时间和上述直接写SQL的时间是几乎一样的。想来,这也是因为distance的计算不能被优化而导致的。。。于是乎,放弃用存储过程

 

 

Tags: mysql, 存储过程

全文索引的苦逼记事二

 继昨天的处理之后,又来新的笔记 ,这次的笔记纯粹是个人的测试,与实际条件有关,比如,我要查询的字段不超过varchar的255的长度,所以我才这么做。

昨天做普通索引后,1100万条记录,索引 为220M,改成全文索引后,索引文件为1.1G,存储空间上,涨了5倍左右。

以下是笔记 ,请不要笑话,场景不同而已

 

  • 经过测试
    • title 字段改为全文索引后,在1100万条的时候
      • 优点:
        • 速度也为0.0x秒级。速度非常快
        • 即使有or条件,只要带了limit参数,速度也非常快
      • 缺点:
        • 如果查询不带limit ,直接卡死,因为他要计算total count
        • select count() 卡死
        • 如果查询不存在的关键字,卡死
    • 使用方法
      • 尽量不做select count 查询 (数量低于100万时可以考虑,超过100万时,其实已经没有必要)
      • 查询一定要带上limit条件
      • 每次查询到不存在的关键字时,记录到关键词库,每次有新增记录时,select 关键词库一下,如果新增房间中有关键字,则将关键词去除,避免卡死
  • 暂时不使用coreseek(sphinx)/xunsearch等第三方工具
    • xunsearch只支持分词查询,不支持完全匹配
    • 第三方工具,耗内存,而且增量的时候,不够及时

Tags: 索引

上月北京游时的一些小吃

 北京游时的小吃:

某天的早饭,骨头汤馄饨,包子是按两卖的,不是按个的。豆腐脑(好奇怪,与南方的完全不一样)

大小: 107.46 K
尺寸: 500 x 375
浏览: 1408 次
点击打开新窗口浏览全图

大小: 91.07 K
尺寸: 500 x 375
浏览: 1598 次
点击打开新窗口浏览全图

大小: 111.42 K
尺寸: 500 x 375
浏览: 1404 次
点击打开新窗口浏览全图

石头带我去的特色,说是豆汁相对比较正宗,认为我喝不下,结果我喝大半碗,觉得还OK。小吃是大杂烩,每样买了点,正好是吃了上述的早饭,然后实在撑不下了。不过我还是吃了好多

大小: 123.05 K
尺寸: 500 x 375
浏览: 1314 次
点击打开新窗口浏览全图

大小: 127.41 K
尺寸: 500 x 375
浏览: 1344 次
点击打开新窗口浏览全图

大小: 138.77 K
尺寸: 500 x 375
浏览: 1370 次
点击打开新窗口浏览全图

大小: 156.61 K
尺寸: 500 x 375
浏览: 1565 次
点击打开新窗口浏览全图

吃的特色馄饨店的馄饨。。(盘子上有字:馄饨候)

大小: 129.73 K
尺寸: 500 x 375
浏览: 1375 次
点击打开新窗口浏览全图

大小: 130.81 K
尺寸: 500 x 375
浏览: 1387 次
点击打开新窗口浏览全图
说这个是玫瑰酥?我一看就觉得是月饼嘛。。上海这种N种花样的月饼太多了,吃了一个,好吧,不太习惯吃这种月饼,上海的月饼我也只吃肉的,比如老大坊的鲜肉月饼,黑黑

全文索引的苦逼记事一

 这是一篇未完成的博客,在这里面做了一点记录

场景:需要做一个关于标题的模糊查询,只是记录有点多,而且需要相对精确,比如搜索:ac, 不能出现abc,可以接受acb,bac,之类。
测试:
1、100万数据,mysql / mongo ,在这种情况下。无论是查询什么数据,基本上都在0.00x秒级,
mysql的查询是like '%xxxx%' , mongo 是 {title:/xxxx/i} 
一般情况下,两者速度真心差不多,但如果查询一下不数据库中不存在的关键字,一般都在0.2秒至2秒左右,mongo会相对好一点,在0.5秒
 
2、500万~1000万数据
查询条件如上
mysql 查询的时候 cpu 占40%左右,20多秒 (mysql 1100万数据)
mongo 查询的时候 CPU占50%左右,10秒/8秒左右 (mongo 550万)
这种性能没法用啊
 
---下一步
1、xunsearch / coreseek(sphinx)
2、mysql 全文索引
 
需要再次测试一下。关键mysql虽然100万只有0.00x或者0.0x秒左右。但是如果多个并发的时候就会卡死了。
所以需要再次考虑 场景的复杂性

Tags: 索引

Shanghai PHP conference 2013(ThinkInLamp)

 早上锅巴在群里发了个链接(http://www.php.net/conferences/)。一看,大为震惊,这真是很难得的事情:

Shanghai PHP conference 2013

ThinkInLAMP is pleased to announce the first Shanghai PHP conference 2013. This event will be held on Sunday June 30th 2013 in Shanghai, China. A community oriented conference which is organized by an excellent line up and socials.

This event will concentrate on PHP languages and web based technologies used today; extension, latest dynamics and new applications within the increased demand for developers and everyone who is interested in PHP language.

There will be more than 500 developers owned over 3 year’s experiences andsenior technical persons come for learning and networking. Register soon as the Early Bird discount rate expires on May 30.

Go to http://php.thinkinlamp.com/2013 for more information, we are looking forward to seeing you in June!

看到这个,你还有什么好犹豫的?赶紧拿起手中的电话,拨打thinkinlamp的参与热线吧