mysql数据库索引查询一个优化大数据量的实例的分享

我们要访问的表是一个非常大的表,四千万条记录,id是主键,program_id上建了索引。
执行一条SQL:
select * from program_access_log where program_id between 1 and 4000

这条SQL非常慢。
我们原以为处理记录太多的原因,所以加了id限制,一次只读五十万条记录
select * from program_access_log where id between 1 and 500000 and program_id between 1 and 4000

但是这条SQL仍然很慢,速度比上面一条几乎没有提升。
Mysql处理50万条记录的表,条件字段还建了索引,这条语句应该是瞬间完成的。

问题分析:

这张表大约容量30G,数据库服务器内存16G,无法一次载入。就是这个造成了问题。
这条SQL有两个条件,ID一到五十万和Program_id一到四千,因为program_id范围小得多,mysql选择它做为主要索引。
先通过索引文件找出了所有program_id在1到4000范围里所有的id,这个过程非常快。
接下来要通过这些id找出表里的记录,由于这些id是离散的,所以mysql对这个表的访问不是顺序读取。
而这个表又非常大,无法一次装入内存,所以每访问一条记录mysql都要重新在磁盘上定位并把附近的记录都载入内存,大量的IO操作导致了速度的下降。

问题解决方案:
1. 以program_id为条件对表进行分区
2. 分表处理,每张表的大小不超过内存的大小
然而,服务器用的是mysql5.0,不支持分区,而且这个表是公共表,无法在不影响其它项目的条件下修改表的结构。
所以我们采取了第三种办法:
select * from program_access_log where id between 1 and 500000 and program_id between 1 and 15000000

现在program_id的范围远大于id的范围,id被当做主要索引进行查找,由于id是主键,所以查找的是连续50万条记录,速度和访问一个50万条记录的表基本一样

总结:
这是一个在千万笔记录表中由于使用了索引导致了数据查找变慢的问题,有一定的典型性和大家交流下!

时间: 2024-10-09 15:10:51

mysql数据库索引查询一个优化大数据量的实例的分享的相关文章

tomcat优化---大数据量提交tomcat时,tomcat无法接收导致页面无反应

关于tomcat的一个优化问题: 有时候保存大数据量的数据时.tomcat不优化的话,页面会没反应.tomcat后台并不报错,仅仅是提示以下内容: 警告: More than the maximum number of request parameters (GET plus POST) for a s ingle request ([10,000]) were detected. Any parameters beyond this limit have be en ignored. To c

mysql数据库索引的一些优化建议

1.独立的索引列.索引不能是表达式的一部分,也就是说索引列不能参与任何计算和函数方法(冲当参数)等. 2.不要肆意使用索引.并不是说为where条件之后的所有查询列都加上索引就一定会提升查询性能. 3.当where后面出现两个以上索引列时,应该考虑使用多列索引. 4.注意索引列的顺序(针对多列索引).将选择性最高的放在前面,比如有两个索引,一个是专业一个班级,那显然筛选专业比筛选班级更快,因为专业数据比班级要少很多. 未完待续--

sql优化之大数据量分页查询(mysql)

当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时就需要使用分页查询.对于数据库分页查询,也有很多种方法和优化的点. 谈优化前的准备工作 为了对下面列举的一些优化进行测试,需要使用已有的一张表作为实际例子. 表名:order_history. 描述:某个业务的订单历史表. 主要字段:unsigned int id,tinyint(4) int type. 字段情况:该表一共37个字段,不包含text等大型数据,最大为varchar(500

大数据量高并发的数据库优化详解(MSSQL)

转载自:http://www.jb51.net/article/71041.htm 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而

mysql数据库索引和视图,触发器

索引简介  跟存储引擎有很大关系其实就是一种排序,生成一种算法,索引主要用在大数据量的时候使用,数据小根本没必要 索引在mysql中也叫做键,是存储引擎用于快速找到记录的一种数据结构,索引对于良好的性能非常关键,尤其是当表中的数据量越来越大的时候,索引对于性能的影响越发重要. 索引优化应该是最查询性能优化的最有效的手段了,索引能够轻易将查询性能提高好几个数量级. 索引相当于字典的音序表,如果要查某个字,如果不使用音序表,则要从几百页中逐页去查. 索引优缺点 优点 加快访问速度 加强行的唯一性 缺

Mysql大数据量问题与解决

今日格言:了解了为什么,问题就解决了一半. Mysql 单表适合的最大数据量是多少? 我们说 Mysql 单表适合存储的最大数据量,自然不是说能够存储的最大数据量,如果是说能够存储的最大量,那么,如果你使用自增 ID,最大就可以存储 2^32 或 2^64 条记录了,这是按自增 ID 的数据类型 int 或 bigint 来计算的:如果你不使用自增 id,且没有 id 最大值的限制,如使用足够长度的随机字符串,那么能够限制单表最大数据量的就只剩磁盘空间了.显然我们不是在讨论这个问题. 影响 My

大数据量数据存储分表实例(企业级应用系统)附原码

随着数据不断增长,数据库中单表无法满足大数据量的存储,所以我们就提出按照自然时间.单站点信息分表来存储大量秒级数据. 例如:大气.水利.交通(GPS)信息监测系统中的实时数据进行存储,一般时按照开始时间.结束时间.单站点.多站点.监测项目等方式进行数据查询.分析.图表. 如 按5分钟单站点的数据12*24(小时)*365(天)*(监测项)10=100W ,也就是一个站点一年数据量 100w条,100站*100W =1亿条这样的数据是无法满足快速查询. 所以我们就按照 "tb_5M_年_站号&qu

MySQL大数据量分页查询方法及其优化

方法1: 直接使用数据库提供的SQL语句 语句样式: MySQL中,可用如下方法: SELECT * FROM 表名称 LIMIT M,N 适应场景: 适用于数据量较少的情况(元组百/千级) 原因/缺点: 全表扫描,速度会很慢 且 有的数据库结果集返回不稳定(如某次返回1,2,3,另外的一次返回2,1,3). Limit限制的是从结果集的M位置处取出N条输出,其余抛弃. 方法2: 建立主键或唯一索引, 利用索引(假设每页10条) 语句样式: MySQL中,可用如下方法: SELECT * FRO

【MySQL】MySQL中针对大数据量常用技术_创建索引+缓存配置+分库分表+子查询优化(转载)

原文地址:http://blog.csdn.net/zwan0518/article/details/11972853 目录(?)[-] 一查询优化 1创建索引 2缓存的配置 3slow_query_log分析 4分库分表 5子查询优化 二数据转移 21插入数据 如今随着互联网的发展,数据的量级也是撑指数的增长,从GB到TB到PB.对数据的各种操作也是愈加的困难,传统的关系性数据库已经无法满足快速查询与插入数据的需求.这个时候NoSQL的出现暂时解决了这一危机.它通过降低数据的安全性,减少对事务