liyihongcug 发表于 2009-6-8 20:38:57

许多语句需要优化 急切询问

许多语句需要优化 急切询问

艰辛的从25m的大日志 (数据库为mysql,但是大家知道, 这些都是相同的哦)挖掘出来下面的慢语句 ,有些我已经解决
但还是希望能抛出问题,集思广益。
1
select distinct id from Outcome where isHistory='N' order by id;

这是我的分析 ,如果有贤人大师更慧眼独具,欢迎指正或者添加
aisHistory 这里不应该设计为字符形, 应该搞为bool或者bit形式 ,
bOutcome 大表,有几十万条记录 ,这里distinct无疑是个巨大的操作,何况还有order by
   查好多材料,据说mysql对orderby支持不是很好,但是业务要用 ,这条语句还是要执行的



(很奇怪 在编辑器跑这条sql,1秒不到就完,但是高峰时间为什么会10几秒都跑不完???)
2select distinct id from BettingOfferwhere isHistory='N' order by id;

同上面类似
3select          log.userId,   max(log.lastLoginTime) lastLoginTime,   count(1) + 1 nrOfLogins from            UserSessionLog loggroup by log.userId order by lastLoginTime desc limit 20;
这条语句过慢 但是确实不知道该如何优化


很困惑 ,几台机器都测试(在线db,测试机器)结果发现这些sql很快,0.7秒不到
问题在慢查询日志记录这些sql是如此之慢 , 到底是什么原因 应该如何解决??

kider 发表于 2009-6-9 14:18:34

首先慢日志中记录的是当时环境下的SQL执行时间,也许那个时机器发生了其他的事情,只是个一个参考值。

其次要找出那个时候的show processlist进程,看看除了你上面的这句,还有其他的SQL没有,会不会有锁竞争等问题....

liyihongcug 发表于 2009-6-10 14:00:44

我该如何发现当时发生的锁(oracle 和sqlserver 可以用工具直接看到 哦)
我现在吧问题细化:
select * from a where isdd='3'几乎每天的慢查询日志都记录这条语句
单执行他不要0.2秒, 但是慢查询日志总是记录他执行3-7秒
观察这个表, insert 和 update相当的多。 当前 他的引擎类型是 myisam
根据innodb是 行级别锁myisam是表级别锁
很多人认为应该更换引擎类型为innodb,楼上同意吗

稀饭 发表于 2009-6-11 13:03:32

可以采用innodb效果会好很多....你的硬件是什么..还有你的select * from a where isdd='3'a表记录有多少..每天多少的insert 和update 如果很大可以考虑分表...

kider 发表于 2009-6-12 14:53:04

insert 和 update相当的多,用innodb好些
页: [1]
查看完整版本: 许多语句需要优化 急切询问