Mysql性能优化教程

VIP免费
2024-12-10 0 0 541.17KB 24 页 5.9玖币
侵权投诉
Mysql 性能优化教程
目录
目录 .................................................................................................................................................. 1
背景及目标....................................................................................................................................... 2
Mysql 执行优 .............................................................................................................................. 2
认识数据索引 ........................................................................................................................... 2
为什么使用数据索引能提高效率 ................................................................................... 2
如何理解数据索引的结构 ............................................................................................... 2
优化实战范例 ................................................................................................................... 3
认识影响结果集 ....................................................................................................................... 4
影响结果集的获 ........................................................................................................... 4
影响结果集的解 ........................................................................................................... 4
常见案例及优化思路 ....................................................................................................... 5
理解执行状态 ........................................................................................................................... 7
常见关注重点 ................................................................................................................... 7
执行状态分析 ................................................................................................................... 8
分析流程 ........................................................................................................................... 9
常见案例解析 ................................................................................................................. 11
总结 ................................................................................................................................. 12
Mysql 运维优 ............................................................................................................................ 14
存储引擎类型 ......................................................................................................................... 14
内存使用考量 ......................................................................................................................... 14
性能与安全性考 ................................................................................................................. 14
存储/写入压力优化 ................................................................................................................ 15
运维监控体系 ......................................................................................................................... 15
Mysql 架构优 ............................................................................................................................ 17
架构优化目标 ......................................................................................................................... 17
防止单点隐患 ................................................................................................................. 17
方便系统扩容 ................................................................................................................. 17
安全可控,成本可控 ..................................................................................................... 17
分布式方案 ............................................................................................................................. 18
分库&拆表方 .............................................................................................................. 18
反范式设计(冗余结构设计) ..................................................................................... 20
主从架构 ......................................................................................................................... 21
故障转移处理 ................................................................................................................. 22
缓存方案 ................................................................................................................................. 22
缓存结合数据库的读取 ................................................................................................. 22
缓存结合数据库的写入 ................................................................................................. 23
总结 ................................................................................................................................................ 24
背景及目标
厦门游家公司(4399.com)用于员工培训和分享。
针对用户群为已经使用mysql 环境,并有一定开发经验的工程师
针对高并发,海量数据的互联网环境。
本文语言为口语,非学术标准用语。
以实战和解决具体问题为主要目标,非应试,非常规教育。友情提醒,在校生学习
本教程可能对成绩提高有害无益
非技术挑战,非高端架构师培训,请高手自动忽略。
本文档在 2011 7-12 月持续更新,加强了影响结果集分析的内容并增补优化实
战案例若干。
Mysql 执行优化
认识数据索引
为什么使用数据索引能提高效率
关系型数据库的数据索引Btree 及常见索引结构)的存储是有序的。
在有序的情况下,通过索引查询一个数据是无需遍历索引记录的
关系型数据库数据索引的查询效率趋近于二分法查询效率,趋近于 log2(N)
极端情况下(更新请求少,更新实时要求低,查询请求频繁),建立单向有序序列
可替代数据索引
HASH 引的查询效率是寻址操作,趋近于 1次查询,比有序索引查询效率更高,
但是不支持比对查询,区间查询,排序等操作仅支持 key-value 类型查询。不是
本文重点。
如何理解数据索引的结构
数据索引通常默认采用 btree 索引,内存表也使用hash 索引)
仅就有序前提而言,单向有序排序序列是查找效率最高的(二分查找或者说折半
查找),使用树形索引的目的是为了达到快速的更新和增删操作。
在极端情况(比如数据查询需求量非常大,而数据更新需求极少,实时性要求不
高,数据规模有限),直接使用单一排序序列,折半查找速度最快。
在进行索引分析和 SQL 优化时,可以将数据索引字段想象为单一有序序列,并以
此作为分析的基础。涉及到复合索引情况,复合索引按照索引顺序拼凑成一个字段,
想象为单一有序序列,并以此作为分析的基础
一条数据查询只能使用一个索引,索引可以是多个字段合并的复合索引。但是一条
数据查询不能使用多个索引。
优化实战范例
实战范例 1 ip 地址反查
资源: Ip地址对应表,源数据格式为 startip, endip, area
源数据条数为 10 条左右,呈很大的分散性
目标: 需要通过任意 ip 查询该 ip 所属地
性能要求达到每1000 次以上的查询效率
挑战: 如使用 between startip and endip 这样的条件数据库操作,因为涉及
两个字段的 between and, 无法有效使用索引。
如果每次查询请求需要遍历 10 万条记录,根本不行。
方法: 一次性排序(只在数据准备中进行,数据可存储在内存序列)
折半查找(每次请求以折半查找方式进行)
实战范例 2:目标:查找与访问者同一地区的异性,按照最后登录时间逆序
挑战:高访问量社区的高频查询,如何优化。
查询 SQL: select * from user where area=$area and sex=$sex order by
lastlogin desc limit 0,30;
建立复合索引并不难, area+sex+lastlogin 个字段的复合索引,如何理解?
解读:首先,忘掉 btree,将索引字段理解为一个排序序列。
另外,牢记数据查询只能使用一个索引,每个字段建立独立索引的情况下
只能有一条索引被使用!
如果只使用 area 会怎样?搜索会把符合 area 结果全部找出来,然后在这里
面遍历,选择命sex 并排序。 遍历所有 area=$area数据!
如果使用了 area+sex略好,仍然要遍历所有 area=$area and sex=$sex数据,
然后在这个基础上排序!
Area+sex+lastlogin 复 合 索 引 时 ( 切 lastlogin 在 最 后 ), 该 索 引 基 于
area+sex+lastlogin 三个字段合并的结果排序,该列表可以想象如下。
广州女$时间 1
广州女$时间 2
广州女$时间 3
广州男
.
深圳女
.
数据库很容易命中到 area+sex 的边界,并且基于下边界向上追溯 30 记录,
搞定!在索引中迅速命中所有结果,无需二次遍历!
认识影响结果集
影响结果集的获取
通过 Explain 分析 SQL,查看 rows 列内容
通过慢查询日志的 Rows_examined: 后面的数字
影响结果集数字是查询优化的重要中间数字,工程师在开发和调试过程中,应随时
关注这一数字。
影响结果集的解读
查询条件与索引的关系决定影响结果集。
影响结果集不是输出结果数,是查询返回的记录数,而是索引所扫描的结
数。
范例 select * from user where area=厦门 and sex=
假设 索引为 area
假设 User 表中 area=厦门的有 125000 条,而搜索返回结果为 60233 条。
影响结果集125000 条,索引先命中 125000 条厦门用户,再遍历以 sex=
进行筛选操作,得到 60233 条结果。
如果该 SQL 增加 limit 0,30 的后缀。查询时先命中 area=厦门然后
依顺序执行 sex= 选操作,直到满足可以返30 条为止,所涉及记
录数未知。除非满足条件的结果不足 30 条,否则不会遍历 125000 条记录
但是如果 SQL 中涉及了排序操作比如 order by lastlogin desc 再有 limit
0,30 时,排序需要遍历所有 area=厦门 的记录,而不是满足即止。
影响结果集越趋近于实际输出或操作的目标结果集,索引效率越高。
影响结果集与查询开销的关系可以理解为线性相关。减少一半影响结果集,即可提
升一倍查询效率当一条搜索 query 可以符合多个索引时选择影响结果集最少的
索引。
SQL 的优化,核心就是对结果集的优化,认识索引是增强对结果集的判断,基于
索引的认识,可以在编写 SQL 的时候,对该 SQL 可能的影响结果集有预判,并做出
适当的优化和调整。
Limit 的影响,需要斟酌对待
如果索引与查询条件和排序条件完全命中,影响结果集就limit 后面的数字
$start + $end,比如 limit 200,30 影响结果集是 230. 而不是 30.
如果索引只命中部分查询条件,甚至无命中条件,在无排序条件情况下,会在
索引命中的结果 中遍历到满足所有其他条件为止。比如 select * from user
limit 10; 虽然没用到索引但是因为不涉及二次筛选和排序,系统直接返回前
10 条结果,影响结果集依然只有 10 条,就不存在效率影响
如果搜索所包含的排序条件没有被索引命中,则系统会遍历是所有索引所命中
的结果,并且排序。例如 Select * from user order by timeline desc limit 10;
timeline 不是索引,响结果集是全表,就存在需要全表数据排序,个效
率影响就巨大。再比如 Select * from user where area=厦门 order by timeline
desc limit 10; 如果 area 是索引,而 area+timeline 未建立索引,则影响结果集
是所有命中 area=厦门的用户,然后在影响结果集内排序。
常见案例及优化思路
毫秒级优化案例
某游戏用户进入后显示最新动态,SQL select * from userfeed where uid=$uid
order by timeline desc limit 20; 主键为$uid SQL 每天执行数百万次之多,
高峰时数据库负载较高。 通过 show processlist 显示大量进程处于 Sending
data 状态。没有慢查询记录。 仔细分析发现,因存在较多高频用户访问,命
uid=$uid 的影响结果集通常在几百到几千,在上千条影响结果集情况下,
SQL 查询开销通常0.01 秒左右 建立 uid+timeline 复合索引,将排序引
入到索引结构中影响结果集就只limit 后面的数字,SQL 查询开销锐减
0.001 秒,数据库负载骤降。
Innodb 锁表案例
某游戏数据库使用了 innodbinnodb 是行级锁,理论上很少存在锁表情况。
出现了一个 SQL 语句(delete from tabname where xid=),这个 SQL 非常用
SQL仅在特定情况下出现,每天出现频繁度不(一天仅 10 次左右)数据
表容量百万级,但是这个 xid 未建立索引,于是悲惨的事情发生了,当执行这
delete 的时候真正删除的记录非常少,也许一到两条,也许一条都没有;
但是!由于这xid 未建立索引,delete 操作时遍历全表记录,全表被 delete
操作锁定,select 操作全部locked,由于百万条记录遍历时间较长,期间大
select 被阻塞,数据库连接过多崩溃。
这种非高发请求,操作目标很少的 SQL,因未使用索引,连带导致整个数据
库的查询阻塞,需要极大提高警觉。
实时排名策略优化
背景: 户提交游戏积分,显示实时排名。
原方案:
提交积分是插入记录,略
select count(*) from jifen where gameid=$gameid and fenshu>$fenshu
问题与挑战
即便索引是 gameid+fenshu 复合索引,涉及 count 作,当分数较低时,
影响结果集巨大,查询效率缓慢,高峰期会导致连接过多。
优化思路
减少影响结果集,又要取得实时数据,单纯从 SQL 上考虑,不太有方法
将游戏积分预定义分成数个积分断点,然后分成积分区间原始状态
个区间设置一个统计数字项,初始为 0
每次积分提交时,先确定该分数属于哪两个区间之间这个操作非常简单,
因为区间是预定义的,而且数量很少,只需遍历即可,找到最该分数符合
的区间, 该区间的统计数字项(独立字段,可用内存处理,异步回写数
据库或文件)+1 录该区间上边界数字为$duandian
SQL: select count(*) from jifen where gameid=$gameid and
fenshu>$fenshu and fenshu<$duandian,如果处于第一区间,则无需
摘要:

Mysql性能优化教程=目录=目录..................................................................................................................................................1背景及目标......................................................................................................................................

展开>> 收起<<
Mysql性能优化教程.pdf

共24页,预览5页

还剩页未读, 继续阅读

声明:本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知玖贝云文库,我们立即给予删除!
分类:计算机 价格:5.9玖币 属性:24 页 大小:541.17KB 格式:PDF 时间:2024-12-10

开通VIP享超值会员特权

  • 多端同步记录
  • 高速下载文档
  • 免费文档工具
  • 分享文档赚钱
  • 每日登录抽奖
  • 优质衍生服务
/ 24
客服
关注