加速query的反应

x^^x

SELECT u.id, u.name, x.gender, x.country, x.marital
FROM user u LEFT JOIN user_extra x ON u.id=x.id
WHERE x.country='US' ...

user_extra 是从user 的 table 扩展出来的，所以user的table row是和user_extra一样的。
问题是当我执行这query时，需时0.7428 sec.

当ORDER BY x.profile_view的时候竟然需时25.3070 sec。
country 是经已index了，不然会更慢！

请问，有任何的办法让他有效率的执行？

winmxaa

原帖由 x^^x 于 4-10-2008 11:18 PM 发表
问题是当我执行这query时，需时0.7428 sec. ...

这个return 多少rows data 回来？

x^^x

不一定的。
最多是千位数。
在query末端，会加LIMIT 40。

两个tables各有2034099 rows.

explain query:

id                                 1                                                        1
select_type                 SIMPLE                                                SIMPLE
table                         x                                                        u
type                                 ref                                                        eq_ref
possible_keys                 PRIMARY,country,country_2                PRIMARY
key                                 country_2                                                PRIMARY
key_len                         8                                                        3
ref                                 const                                                test.x.id
rows                         37684                                                1
Extra                        Using where; Using filesort                        Using where

x^^x

抱歉，没看清你的问题。
那个query return 43,424 rows。

k-1

user_extra.profile_view 有放 index 吗？

winmxaa

原帖由 k-1 于 5-10-2008 12:23 PM 发表
user_extra.profile_view 有放 index 吗？

对放index在profile_view，因为你讲有43,424 rows，会很慢的。
如果回来100rows 就不用放，database是很生动的，你要多观察！

x^^x

index的不好之处在于Insert和Update的时候比较慢，不是吗？

当User的Profile被浏览时，profile_view会+1。频繁的Update适用于Index?

那个query里的Order By, 不是每次都是profile_view。
User可以选择sort by Popularity、New Member或者Last Login的。

New Member 的可以Order By member_id DESC （PK 是已经被system index起来了）,
是不是Last Login 也要Index起来？

winmxaa

index的不好之处在于Insert和Update的时候比较慢，不是吗？
对

当User的Profile被浏览时，profile_view会+1。频繁的Update适用于Index?
不适合

那个query里的Order By, 不是每次都是profile_view。
User可以选择sort by Popularity、New Member或者Last Login的。
你要一早跟我们讲你的condition

New Member 的可以Order By member_id DESC （PK 是已经被system index起来了）,
是不是Last Login 也要Index起来？
index 来做莫？

x^^x

New Member 的可以Order By member_id DESC （PK 是已经被system index起来了）,
是不是Last Login 也要Index起来？
index 来做莫？

就是希望Select的时候快点。
可是这些Column （Last Login和profile_view）都会时常Update的，
都不知该不该Index起来。

winmxaa

原帖由 x^^x 于 5-10-2008 06:48 PM 发表


就是希望Select的时候快点。
可是这些Column （Last Login和profile_view）都会时常Update的，
都不知该不该Index起来。

profile_view你要来order
Last Login也要order么？

x^^x

不不不，
Order By只是任选一样罢了(profile_view, Last Login or id)。

mokth

Actually, do u need those few thousands records to return back to u application at 1 query. This not only will make the network "traffic jam" and also hurt the server performance. Imagine, if u have 10 users request those few thousands records (or even more), what will happen to u server or u network traffic. Try to implement the paging concept (either web/wind form application). U query slow, u may try to check u server configuration. Or u may try to use inner join instead of left outer join. Outer join will return the empty (null) data if does no meet the condition while inner join will only return those data that meet the query criteria.

twigky

不介意放你的table script上来？
很有趣的topic...

tensaix2j

是否可以先 filter 掉 那个 US 的， 后再 join 或什么的。。

因为先 join就好象  n row 乘  n row 那么多的checking。。。

先 filter 掉之后  后再 join 或许 只剩下  (n - f) * (n - f )

CoLoUrGhOsT

since your data so much, can consider partition your table