j****k
发帖数: 91 | 1 背景:
数据库很大, billion级别的记录条数, 有很多子表.
为了优化我设置一个limit来限制返回的记录数, 对于可以查到结果的pattern, 效果很
好; 但是对于在数据库里没有match的pattern, Query就必须做一次全表扫描, 非常慢.
请问如何优化这种查不到数据的Query? |
x******i
发帖数: 391 | 2 仅仅limit返回记录数就可以提高query的运行速度？query的优化是不是应该从TABLE
JOIN,where condition，and index开始？避免子集操作，e.g.in，NOT IN。
index是不是标准答案？ |
B*****g
发帖数: 34098 | 3 sql优化？应该从设计开始，sql自己远着呢。
【在 x******i 的大作中提到】
: 仅仅limit返回记录数就可以提高query的运行速度？query的优化是不是应该从TABLE
: JOIN,where condition，and index开始？避免子集操作，e.g.in，NOT IN。
: index是不是标准答案？
|
c*****d
发帖数: 6045 | 4 不理解lz说的是什么意思
select * from emp where empno=8848
不管emp表中是否有8848这个记录，如果empno上有index都会用index lookup
慢.
【在 j****k 的大作中提到】
: 背景:
: 数据库很大, billion级别的记录条数, 有很多子表.
: 为了优化我设置一个limit来限制返回的记录数, 对于可以查到结果的pattern, 效果很
: 好; 但是对于在数据库里没有match的pattern, Query就必须做一次全表扫描, 非常慢.
: 请问如何优化这种查不到数据的Query?
|
j*****n
发帖数: 1781 | 5 I doubt this query even had suitable index. by limiting number of returns
had good performance is just it is lucky that had enough number before scan
hits deeper. of course a full scan causes if no return or less number of
returns than the limit.
【在 c*****d 的大作中提到】
: 不理解lz说的是什么意思
: select * from emp where empno=8848
: 不管emp表中是否有8848这个记录，如果empno上有index都会用index lookup
:
: 慢.
|
g***l
发帖数: 18555 | 6 BILLION以后可以用TABLE PARTITION，或者子TABLE按照常用的COLUMN VALUE分开，这
样直接QUERY子表块多了 |
a*******s
发帖数: 324 | 7 同意。
而且当你想查是否有某个pattern时，你是必须知道所有信息的才能保证100%对的。所
以提前加index,或者全扫描，都是为了得到全部信息。
你可以就一次全扫描去检验所有的想查的pattern,像什么sum(case when *** like "
pattern" then 1 else 0).
scan
【在 j*****n 的大作中提到】
: I doubt this query even had suitable index. by limiting number of returns
: had good performance is just it is lucky that had enough number before scan
: hits deeper. of course a full scan causes if no return or less number of
: returns than the limit.
|
j****k
发帖数: 91 | 8 背景:
数据库很大, billion级别的记录条数, 有很多子表.
为了优化我设置一个limit来限制返回的记录数, 对于可以查到结果的pattern, 效果很
好; 但是对于在数据库里没有match的pattern, Query就必须做一次全表扫描, 非常慢.
请问如何优化这种查不到数据的Query? |
x******i
发帖数: 391 | 9 仅仅limit返回记录数就可以提高query的运行速度？query的优化是不是应该从TABLE
JOIN,where condition，and index开始？避免子集操作，e.g.in，NOT IN。
index是不是标准答案？ |
B*****g
发帖数: 34098 | 10 sql优化？应该从设计开始，sql自己远着呢。
【在 x******i 的大作中提到】
: 仅仅limit返回记录数就可以提高query的运行速度？query的优化是不是应该从TABLE
: JOIN,where condition，and index开始？避免子集操作，e.g.in，NOT IN。
: index是不是标准答案？
|
c*****d
发帖数: 6045 | 11 不理解lz说的是什么意思
select * from emp where empno=8848
不管emp表中是否有8848这个记录，如果empno上有index都会用index lookup
慢.
【在 j****k 的大作中提到】
: 背景:
: 数据库很大, billion级别的记录条数, 有很多子表.
: 为了优化我设置一个limit来限制返回的记录数, 对于可以查到结果的pattern, 效果很
: 好; 但是对于在数据库里没有match的pattern, Query就必须做一次全表扫描, 非常慢.
: 请问如何优化这种查不到数据的Query?
|
j*****n
发帖数: 1781 | 12 I doubt this query even had suitable index. by limiting number of returns
had good performance is just it is lucky that had enough number before scan
hits deeper. of course a full scan causes if no return or less number of
returns than the limit.
【在 c*****d 的大作中提到】
: 不理解lz说的是什么意思
: select * from emp where empno=8848
: 不管emp表中是否有8848这个记录，如果empno上有index都会用index lookup
:
: 慢.
|
g***l
发帖数: 18555 | 13 BILLION以后可以用TABLE PARTITION，或者子TABLE按照常用的COLUMN VALUE分开，这
样直接QUERY子表块多了 |
a*******s
发帖数: 324 | 14 同意。
而且当你想查是否有某个pattern时，你是必须知道所有信息的才能保证100%对的。所
以提前加index,或者全扫描，都是为了得到全部信息。
你可以就一次全扫描去检验所有的想查的pattern,像什么sum(case when *** like "
pattern" then 1 else 0).
scan
【在 j*****n 的大作中提到】
: I doubt this query even had suitable index. by limiting number of returns
: had good performance is just it is lucky that had enough number before scan
: hits deeper. of course a full scan causes if no return or less number of
: returns than the limit.
|
