云数据库十大经典案例

《云数据库十大经典案例》由会员分享，可在线阅读，更多相关《云数据库十大经典案例（52页珍藏版）》请在金锄头文库上搜索。

1、云 数据库十大经典案例ApsaraDB专家 服务 组玄 惭自我介绍 玄惭出自天龙八部 2010年加入淘宝 DBA 2012年加入阿里云 RDS 负责 RDS线上的稳定 历年 RDS双 11的 负责人 RDS专家服务组负责人 博 客： hidba.org目 录案例一 索引案例二 SQL优化案例三 锁案例四 延迟案例五 参数优化案例六 conn 100%案例七 cpu 100%案例八 iops 100%案例九 disk 100%案例十 mem 100%一、案例一 索引案例 一 无 索引案例问题描述 ： 用户系统打开缓慢，数据库 CPU 100%问题 排查 ： 发现数据库中大量 的慢 sql，执行时

2、间超过了 2S慢 SQL： SELECT uid FROM user WHERE mo=13772556391 LIMIT 0,1;执行 计划mysql explain SELECT uid FROM user WHERE mo=13772556391 LIMIT 0,1;* 1. row *id: 1select_type: SIMPLEtable: usertype: ALLpossible_keys: NULLkey: NULLkey_len: NULLref: NULLrows: 707250Extra: Using where执行时间mysql SELECT uid FROM use

3、r WHERE mo=13772556391 LIMIT 0,1; Empty set (2.11 sec)案例 一 无 索引案例表结构CREATE TABLE user (uid int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT id,pid int(11) unsigned NOT NULL DEFAULT 0 ,email char(60) NOT NULL ,name char(32) NOT NULL DEFAULT ,mo char(11) NOT NULL DEFAULT ,PRIMARY KEY (uid),UNIQUE KEY

4、email (email),KEY pid (pid) ENGINE=InnoDB ENGINE=InnoDB AUTO_INCREMENT=972600 DEFAULT CHARSET=utf8;案例 一 无 索引案例验证 mo字段的过滤性mysql select count(*) from user where mo=13772556391;+-+| count(*) |+-+| 0 |+-+1 row in set (0.05 sec)添加索引mysql alter table user add index ind_mo(mo);执行时间mysqlSELECT uid FROM user

5、 WHERE mo=13772556391 LIMIT 0,1;Empty set (0.05 sec)案例一 无索引案例执行计划mysql explain SELECT uid FROM user WHERE mo=13772556391 LIMIT 0,1G;* 1. row *id: 1select_type: SIMPLEtable: usertype: indexpossible_keys: ind_mokey: ind_mokey_len: 33ref: NULLrows: 707250Extra: Using where; Using index案例一 隐式转换案例为什么索引的过

6、滤性这么差 ？mysql explain extended select uid fromuser where mo=13772556391 limit 0,1;mysql show warnings;Warning1： Cannot use index ind_mo due to type or collation conversion on field mo Note： select user.uid AS uid from user where (user.mo = 13772556391) limit 0,1表结构CREATE TABLE user (mo char(11) NOT N

7、ULL DEFAULT ,) ENGINE=InnoDB;案例一 隐式转换案例mysql explain SELECT uid FROM user WHERE mo=13772556391 LIMIT 0,1G;* 1. row *id: 1select_type: SIMPLEtable: usertype: refpossible_keys: ind_mokey: ind_mokey_len: 33ref: constrows: 1Extra: Using where; Using indexmysql SELECT uid FROM user WHERE mo=13772556391 L

8、IMIT 0,1;Empty set (0.00 sec)123通过 explain查看 sql的执行 计划判断是否使用到了索引以及隐士转换常见的隐 式 转换包括字段数据类型类型以及字符集定义不当导致设计开发阶段避免数据库字段定义与应用程序参数定义出现不 一致不支持函数索引 ,避免在查询条件加入函数 :date(a.gmt_create)索引最佳实践4SQL审核所有上线的 sql都要经过严格的审核，创建合适的索引二、案例二 SQL优化案例二 分页优化案例| Query | 51 | Sending data | select *from buyerwhere sellerId = 765922

9、982 and gmt_modified = 1970-01-01 08:00:00 and gmt_modified = 1970-01-01 08:00:00 and gmt_modified = 1970-01-01 08:00:00 and gmt_modified MySQL、 ORALCE-MySQL）2、 跨版本升级 (MySQL:5.1-5.5、 5.5-5.6)3、 执行计划，优化器，参数配置，硬件配置案例 五 一个参数引发的血案确定 优化器版本：用户 5.6， RDS的版本 5.6OPTIMIZER_SWITCH:index_merge=on,index_merge_uni

10、on=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensi

11、ons=on案例 五 一个参数引发的血案确定 SQL执行计划： rows=39900*1*1*140*285*1*1*1*1*1*1*1案例 五 一个参数引发的血案确定 参数 配置用户配置：join_buffer_size = 128Mread_rnd_buffer_size = 128Mtmp_table_size = 128MRDS配置join_buffer_size = 1Mread_buffer_size = 1Mtmp_table_size =256K案例 五 一个参数引发的血案验证阶段： tmp_table_size由 256K调整至 128MB12排 查思路1.查看 SQL执行计

12、划；2.查看数据库版本和优化器规则；3.对比参数设置 ；4.对比硬件配置；最佳实践1.Query_cache_size；2.Temp_table_size3.Tokudb_buffer_pool_ratio4.Back_log参数最佳 实践六 、案例六 cpu 100%案例 六 cpu 100%三大因素：慢 SQL，锁，资源12慢 SQL问题1.通过优化索引，子查询，隐士转换，分页改写等优化；锁等待问题1.通过设计开发和管理运维优化锁等待；Cpu 100%最佳 实践3资源问题1.通过参数优化，弹性升级，读写分离，数据库拆分等方式优化；七 、案例 七 conn 100%案例 七 conn 100

13、%三大因素：慢 SQL，锁，配置12慢 SQL问题1.通过优化索引，子查询，隐士转换，分页改写等优化；锁等待问题1.通过设计开发和管理运维优化锁等待；Conn 100%最佳 实践3配置 问题1.客户端连接池参数配置超出实例最大连接数；2.弹性升级 RDS的规格配置；八、案例八 iops 100%12慢 SQL问题1.通过优化索引，子查询，隐士转换，分页改写等优化；DDL1. create index， optimze table， alter table add column ；Iops 100%最佳 实践3配置 问题1.内存规格不足，弹性升级 RDS的规格配置；九、案例九 disk 100%

14、案例九 disk 100%磁盘空间组成：数据文件，日志文件，临时文件12数据空间问题1.采用 optimize table收缩表空间；删除不必要的索引；2.使用 tokudb压缩引擎；日志空间问题1.减少大字段的使用；2.使用 truncate 替代 delete from；空间最佳 实践3临时 空间问题1.适当调大 sort_buffer_size；2.创建合适索引避免排序；十 、案例十 mem 100%案例十 mem 100%内存组成： Buffer pool size ， Dictionary memory， Thread cost memory12Buffer pool size 1.创建合适的索引，避免大量的数据扫描；2.去除不必要的索引，降低内存的消耗；Thread cost memory1.创建合适的索引避免排序；2.只查询应用所需要的数据；内存 最佳 实践3Dictionary memory1.不要过度分表；Thank you !