用的是mysql数据库,有个表每天都会新增100--200万条数据
曾经考虑从业务上减小该表数据量,但是不符合需求。
现状就是每天都有起码100万条数据进入这个表, 但每个月该表都会自动清零,也就是说这个表的数据最多3000万--6000万条前台对这个表会做类似下面的Sql操作!
select
filed1,
sum(filed2+filed3) as sumFiled
from
tabA
where
filed4>? and
filed5=? and
filed6=? and
stime<=? and
stime>=?
group by 1
order by 2
limit ?
但由于数据量太大,响应的太慢了。不知道有没有什么办法啊。 也不奢望能有什么办法可以效率特别高,只是希望大家能提点优化的意见,哪怕提高一点也好啊。
麻烦大家了啊!
这个表现在的现状:1、表的字段不多,大概10个。
2、现在就只做了pk的index,其他都没有做啊。
3、表是innodb类型啊
4、暂时不能考虑集群。
5、Mysql也是默认安装的,没有修改任何的参数。
以前也听人说、什么垂直分割水平分割,什么用Insert的单独做,然后启动多个Mysql做集群,专门做查询用,什么的,但也不知道具体怎么做。
现在思路就是,想从Mysql配置文件什么的做点优化, 然后从表这块做点优化。
不知道有人能提供点优化办法吗?也不奢望能有什么办法可以有质的飞跃啊,只是希望大家能提点优化的意见,哪怕提高一点也好啊。5555
解决了放500分啊。感谢大家了很头疼555
曾经考虑从业务上减小该表数据量,但是不符合需求。
现状就是每天都有起码100万条数据进入这个表, 但每个月该表都会自动清零,也就是说这个表的数据最多3000万--6000万条前台对这个表会做类似下面的Sql操作!
select
filed1,
sum(filed2+filed3) as sumFiled
from
tabA
where
filed4>? and
filed5=? and
filed6=? and
stime<=? and
stime>=?
group by 1
order by 2
limit ?
但由于数据量太大,响应的太慢了。不知道有没有什么办法啊。 也不奢望能有什么办法可以效率特别高,只是希望大家能提点优化的意见,哪怕提高一点也好啊。
麻烦大家了啊!
这个表现在的现状:1、表的字段不多,大概10个。
2、现在就只做了pk的index,其他都没有做啊。
3、表是innodb类型啊
4、暂时不能考虑集群。
5、Mysql也是默认安装的,没有修改任何的参数。
以前也听人说、什么垂直分割水平分割,什么用Insert的单独做,然后启动多个Mysql做集群,专门做查询用,什么的,但也不知道具体怎么做。
现在思路就是,想从Mysql配置文件什么的做点优化, 然后从表这块做点优化。
不知道有人能提供点优化办法吗?也不奢望能有什么办法可以有质的飞跃啊,只是希望大家能提点优化的意见,哪怕提高一点也好啊。5555
解决了放500分啊。感谢大家了很头疼555
filed4
filed5
filed6
stime
的索引,然后贴出你的 show index from tabA ;或者你能直接说明一下这些字段的中预计数据分布.
一台服务器(实时数据库服务器)专门insert;另外一台备份数据库服务器专门select,根据查询条件建索引。10分钟左右备份一次(根据实际情况定)
filed5 ???然后再看 不同值最多,分布均匀的之后是哪个? 依据这个来平衡所需要创建的复合索引。
建议你还是
否则估计你还是继续问下去。解释起来比较复杂,帮助手册中讲了几千字。
max_allowed_packet = 10M
table_cache = 256
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
(filed5,filed6)
建议不要贴图,有时看不到,自然有忽略了。 象下面一样贴文本,这样别人也容易分析。
mysql> show index from t1;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| t1 | 0 | PRIMARY | 1 | id | A | 499999 | NULL | NULL | | BTREE | |
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
1 row in set (0.25 sec)mysql>
http://dev.mysql.com/doc/refman/5.1/zh/optimization.html
7. 优化
7.1. 优化概述
7.1.1. MySQL设计局限与折衷
7.1.2. 为可移植性设计应用程序
7.1.3. 我们已将MySQL用在何处?
7.1.4. MySQL基准套件
7.1.5. 使用自己的基准
7.2. 优化SELECT语句和其它查询
7.2.1. EXPLAIN语法(获取SELECT相关信息)
7.2.2. 估计查询性能
7.2.3. SELECT查询的速度
7.2.4. MySQL怎样优化WHERE子句
7.2.5. 范围优化
7.2.6. 索引合并优化
如果是查询,则必须指定时间范围。如果跨多天,可以使用Union,必须确保使用了索引。
当然,如果时间跨度太大,索引会失效。索引查询的数据量不能超过总数据量的30%。2 可以考虑搭建主备机制,采用多台备机,分担查询压力。保障主备不延迟即可。3 优化查询需求。确认这些查询是否必须实时查询出来不可?
如果不是一定需要实时,可以定期跑出数据,放在一个结果集里。前台只需要查询这个结果集。4 如果一定要跨天查询。每天夜间,对前一天的数据进行预处理。使得查询可以在预处理后的数据基础上查询。避免事实查多次。5 数据库不能解决所有的问题,必须结合应用进行优化。最好的版本就是分表,预处理查询结果。
另外你的SQL语句不太合理。或者说太不合理。
比如你那么多WHERE条件的组合,我认为可以分切为联合查询或者子查询吧,
而limit的使用,这样用就彻底错了,虽然可以给你正确的结果,但mysql是以遍历了你的查询结果集做到的,
limit建立你应子查询来实现。