3千万行记录的表,提高查询效率

Tedd 发布于 2013/11/08 09:19
阅读 1K+
收藏 4

有一个3千万行记录的表,表里有个字段是记录的时间,现在需要根据这个时间查询一段范围内的数据,另外还要关联其它几个表,做联合查询,最终需要的数据是联合查询出来的结果.

现在查询一天的数据就要跑300s以上,有啥办法可提高点效率?

SELECT
    i.key_,
    date(
        FROM_UNIXTIME(h.clock)
    )AS the_date,
    i.delay,
    sum(
        (delay / 60)* h.
    VALUE


    )AS up_time,
    hs. NAME,
    g. NAME
FROM
    history_uint h
JOIN items i ON h.itemid = i.itemid
JOIN hosts_groups p ON i.hostid = p.hostid
JOIN groups g ON p.groupid = g.groupid
INNER JOIN `hosts` hs ON p.hostid = hs.hostid
WHERE
    g. NAME = 'group_name'
AND i.key_ = 'key_name'
AND h.clock >= UNIX_TIMESTAMP(
    '2013-11-06 00:00:00'
)
AND h.clock <= UNIX_TIMESTAMP(
    '2013-11-06 23:59:59'
)
AND h.
VALUE
    >= 1
GROUP BY
    hs. NAME,
    the_date

加载中
0
Tuesday
Tuesday

一直不明白, 为什么写这么复杂的查询语法.

这说明设计表有问题.....
UNIX_TIMESTAMP(

28

   '2013-11-06 23:59:59'

你不会转成时间秒再放进去?

Tedd
Tedd
这是zabbix的数据库,需要在zabbix里取数据,才要查它的这些表的.可是history那个表太大了
0
梅开源
梅开源
分表吧
Tedd
Tedd
对数据库这块不太熟,刚看了下,涉及到分表操作好像挺复杂的,需要DBA?我们目前对这个库只有读的权限.
0
wx---每日佳选
wx---每日佳选
提前统计出来放进其它表里。sql无法优化的时候可以想其它办法的。
Tedd
Tedd
后台定时跑...查询的时候取跑出来的数据.. 哎,如果他们不弄表,估计只有这样搞了.
铂金胖子
铂金胖子
+1
0
老陌
老陌
1. where 中用 UNIX_TIMESTAMP函数就用不到索引了,看看能不能把时间提前计算好, 如果实在因为业务问题不能, 也把where条件中 h.value>=1 放到前面

2. 看看是不是对  g.name, h.clock, i.key, h.value, hs.name 加上 索引了(还有join涉及的字段)

3. 把 group by 中 the_date 直接换成 h.clock

然后看看执行计划什么的

0
中山野鬼
中山野鬼
哈,这种问题,基本上回答是,硬件规模搞大点,表的设计优化点,ok。等你什么时候是13亿的数据在查,折腾不懂,那估计才是结构性问题。
0
宏哥
宏哥

引用来自“中山野鬼”的答案

哈,这种问题,基本上回答是,硬件规模搞大点,表的设计优化点,ok。等你什么时候是13亿的数据在查,折腾不懂,那估计才是结构性问题。

数据库其实就是以空间换时间.

只要不是全表扫描,  基本上, 速度不会受到数据数量的太大影响.

查询的速度, 是以匹配数据的规模来决定的.

13123123
13123123
还有一种把时间换成 秒数吧
13123123
13123123
可以把年月份 放一个字段 时间秒放一个字段 然后查询 应该会有所提高吧
乌龟壳
乌龟壳
确实,基准速度是和涉及到的数据规模有直接关系的,在设计良好的数据库下,能尽可能减少操作涉及到的规模。
0
中山野鬼
中山野鬼

引用来自“宏哥”的答案

引用来自“中山野鬼”的答案

哈,这种问题,基本上回答是,硬件规模搞大点,表的设计优化点,ok。等你什么时候是13亿的数据在查,折腾不懂,那估计才是结构性问题。

数据库其实就是以空间换时间.

只要不是全表扫描,  基本上, 速度不会受到数据数量的太大影响.

查询的速度, 是以匹配数据的规模来决定的.

必要时,数据的存储结构还是要和业务逻辑中大概率的高计算量进行关联。通用的的数据模型和数据处理方式,并不能解决所有特定问题。哈。
乌龟壳
乌龟壳
函数索引,范围索引
0
指尖的舞者
指尖的舞者

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

引用来自“中山野鬼”的答案

哈,这种问题,基本上回答是,硬件规模搞大点,表的设计优化点,ok。等你什么时候是13亿的数据在查,折腾不懂,那估计才是结构性问题。

数据库其实就是以空间换时间.

只要不是全表扫描,  基本上, 速度不会受到数据数量的太大影响.

查询的速度, 是以匹配数据的规模来决定的.

必要时,数据的存储结构还是要和业务逻辑中大概率的高计算量进行关联。通用的的数据模型和数据处理方式,并不能解决所有特定问题。哈。
您这个回答仍然类似你自己说的“硬件规模搞大点,表的设计优化点,ok。”  
0
中山野鬼
中山野鬼

引用来自“指尖的舞者”的答案

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

引用来自“中山野鬼”的答案

哈,这种问题,基本上回答是,硬件规模搞大点,表的设计优化点,ok。等你什么时候是13亿的数据在查,折腾不懂,那估计才是结构性问题。

数据库其实就是以空间换时间.

只要不是全表扫描,  基本上, 速度不会受到数据数量的太大影响.

查询的速度, 是以匹配数据的规模来决定的.

必要时,数据的存储结构还是要和业务逻辑中大概率的高计算量进行关联。通用的的数据模型和数据处理方式,并不能解决所有特定问题。哈。
您这个回答仍然类似你自己说的“硬件规模搞大点,表的设计优化点,ok。”  
表的设计优化点,和数据结构的设计不是一回事。你的表设计优化,始终建立在已确定的数据存储和操作结构上。最简单的例子是,你使用oracle ,mysql 还是其他,一旦选定这些基础数据库平台,那么他们特有的数据操作方式,会限制某些业务逻辑的实现。没有哪个基础数据库平台是能大一统解决任何问题的。要不然现在nosql的也不会发展起来,不过反过来,nosql的没事情去做oracle擅长的,也一定是sb行为。哈。
0
微酷
微酷
按日期分区存储
一位极其不愿意透漏姓名的马先生
一位极其不愿意透漏姓名的马先生
就是垂直平分表嘛
返回顶部
顶部