【RDS系列二】别总等数据库宕了才想起我-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

【RDS系列二】别总等数据库宕了才想起我

belle.zhoux 2015-04-20 10:27:42 18251
遇到过很多朋友跟技术团队,平时的精力都放在前端的业务开发上,不遇到问题是不太会关注数据库的。只有当数据库宕了才火急火燎的去找问题根源所在。其实RDS提供了实例诊断和性能优化的功能。

1.慢SQL统计和SQL运行报告
RDS会将用户连接使用数据库中的慢SQL进行相似语句去重,并按照指定方式排序后进行展示,为用户排查慢SQL优化数据库性能提供帮助。SQL运行报告中记录了用户在数据库上执行的所有SQL,可以方便用户了解业务SQL的分布情况。 对于出现的慢SQL,用户可同时根据SQL运行报告中这些慢SQL的运行规律,做重点优化,提升RDS性能。
关于如何根据慢SQL统计和SQL运行报告对数据库进行优化。请移步这里》

2.存储引擎检查、主键检查和大表检查
A.存储引擎检查,检查数据库存储引擎的问题,必要时会给出建议。例如,我们建议使用INNODB存储引擎,INNODB引擎的好处在于:
(1)INNODB具有完整事务特性支持,MyISAM不支持事务;
(2) INNODB支持行级锁,有更高的数据并发存取效率,即更高的TPS;MyISAM只支持表级锁,在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,会阻塞对同一表的写请求,从而导致连接堆积,连接数上涨。
(3)数据库实例异常重启后,InnoDB表能自动修复,而且速度相对更快,而MyISAM需要被触发才能修复,且相对耗时可能多4~5倍甚至更多;
(4)更高的数据读取性能,因为InnoDB把数据及索引同时缓存在内存中,而MyISAM只缓存了索引。
(5)在线备份时,MyISAM会锁表,而INNODB不会。


B. 主键检查, 检查数据库中没有创建主键的表。建议大家使用自增id作为主键,好处在于:
(1)自增型主键以利于插入性能的提高
(2)对于MySQL而言,自增型主键设计可以降低二级索引的空间


C. 大表检查, 检查数据表大于2G的表。

3. 索引偏多和索引缺失
RDS会根据运行情况,系统将提示哪些数据库表中的索引偏多,建议用户修改表结构。同时RDS会根据SQL语句运行情况及性能,系统将提示缺失索引的数据库表,并提示添加索引的SQL语句。

4.其他
根据数据库的运行状况,必要时会给出其他优化建议。

对于索引偏多和索引缺失的问题如何优化。以及其他数据库的异常运行情况进行优化。5月我们会继续邀请专家坐诊,各位朋友有什么疑问要解答的,也请准备好哦!


SQL 存储 缓存 前端开发 关系型数据库 MySQL 数据库 索引 RDS
分享到
取消 提交回答
全部回答(15)
  • 朝夕网
    2015-05-01 19:37:43
    回5楼mumu87301的帖子
    你那么多数据使用like肯定不行

    简单点使用《全文索引》
    复杂点使用搜索引擎技术,有些开源系统也挺好用的
    0 0
  • 如此
    2015-04-30 22:22:21
    Re【RDS系列二】别总等数据库宕了才想起我
    小站长用不起啊!
    0 0
  • www.szbbs.cc
    2015-04-28 10:31:48
          

    -------------------------

      支持 淘宝打折网:http://www.shazhekou.com/      

    0 0
  • 小柒2012
    2015-04-24 09:04:29
    的的确确 不错
    0 0
  • 俞月
    2015-04-23 22:25:15
    回9楼淡然随心的帖子
    如果你在那个时候就用到了RDS,就不用担心数据丢失了。
    RDS提供了恢复到7天之内的任意时间点功能,只需要在控制台上点点按钮,就能恢复到数据丢失前的时间点。
    其原理是这样的:
    假如要恢复到4月22日中午12:00, 先会拿到该时间点之前最近的一个物理备份集,恢复出全量的数据;再应用从物理备份的时间点到4月22日中午12:00之间的binlog。
    所以为了数据安全,建议大家尽量选择每天都做一次物理备份,这些备份集都是免费存在阿里云OSS上的,不占用户空间的。

    -------------------------

    回8楼狂奔の蜗牛的帖子
    账号权限开放、支持binlog备份的付费服务,都在产品的排期之内的。RDS团队还在加紧开发。

    RDS open API支持查询、下载binlog的。OPEN API文档中有相关接口的说明。

    -------------------------

    回5楼mumu87301的帖子


    先可以看查询所返回的结果集,通常如果返回的结果集很少,是有信心进行优化的。
    需要在过滤性强的字段上建立合适的索引。

    使用like进行模糊查询,由于like '%XXXX%'不符合前缀匹配的规则,所以用不上索引,需要全表扫描。
    比如在下面的表结构下查询:
           Table: tunning_missindex
    Create Table: CREATE TABLE `test1` (
      `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
      `custins_id` int(10) unsigned NOT NULL DEFAULT '0',
      `db_name` varchar(128) DEFAULT NULL ,
      `table_name` varchar(128) DEFAULT NULL ,
       ...........
       ...........
      `gmt_created` datetime NOT NULL ,
      `gmt_modified` datetime NOT NULL ,
      `creator` int(11) unsigned DEFAULT '0' ,
      `modifier` int(11) unsigned DEFAULT '0' ,
      `tuning_advice` text,
      PRIMARY KEY (`id`),
      KEY `idx_tablename` (`table_name`)
    ) ENGINE=InnoDB AUTO_INCREMENT=12749 DEFAULT CHARSET=utf8

    mysql> explain select * from test1 where table_name like '%test%';
    +----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
    | id | select_type | table             | type | possible_keys | key  | key_len | ref  | rows  | Extra       |
    +----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
    |  1 | SIMPLE      | test1 | ALL  | NULL          | NULL | NULL    | NULL | 10382 | Using where |
    +----+-------------+-------------------+------+---------------+------+---------+------+-------+-------------+
    1 row in set (0.00 sec)

    InnoDB表是按照聚簇索引组织的。InnoDB通过主键聚簇数据,如果没有定义主键,会选择一个唯一的非空索引代替,如果没有这样的索引,会隐式定义个主键作为聚簇索引。
    对于聚簇索引表来说,表数据是和主键一起存储的,主键索引的叶结点存储行数据,二级索引的叶结点存储行的主键值。
    所以,理想情况应该是这个流程
    1)       遍历table_name索引,从中读取和过滤所有table_name中匹配like条件的id
    2)       用id到聚簇索引中读数据。

    对于 select count(*) from test1 where table_name like '%test%'的优化,可以利用到覆盖索引。这样扫描二级索引就可以得到结果,避免再到数据行去查询。
    mysql> explain select count(*) from test1 where table_name like '%test%';
    +----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
    | id | select_type | table             | type  | possible_keys | key           | key_len | ref  | rows  | Extra                    |
    +----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
    |  1 | SIMPLE      | test1 | index | NULL          | idx_tablename | 387     | NULL | 10382 | Using where; Using index |
    +----+-------------+-------------------+-------+---------------+---------------+---------+------+-------+--------------------------+
    1 row in set (0.00 sec)

    通过覆盖索引可以获得性能上的一定优化,但是在数据量特别大,请求频繁的业务场景下不要在数据库进行模糊查询;  
    非得使用数据库的话 ,建议不要在生产库进行查询,可以在只读节点进行查询,避免查询造成主业务数据库的资源消耗完,导致故障.  
    可以使用一些开源的搜索引擎技术,比如sphinx.  

    sql优化的时候遵循T=S/V的原则:
    S指SQL所需访问的资源总量,V指SQL单位时间所能访问的资源量,T自然就是SQL执行所需时间了;我们为了获得SQL最快的执行时间,可以根据公式定义上去反推:

    在S不变的情况下,我们可以提升V来降低T:通过适当的索引调整,我们可以将大量的速度较慢的随机IO转换为速度较快的顺序IO;通过提升服务器的内存,使得将更多的数据放到内存中,会比数据放到磁盘上会得到明显的速度提升;

    在V不变的情况下,我们可以减小S来降低T:这是SQL优化中非常核心的一个环节,在减小S环节上,我们可以做的可以有很多,通常可以在查询条件中建立适当的索引,来避免全表扫描;有时候可以改写SQl,添加一些适当的提示符,来改变SQL的执行计划,使SQL以最少的扫描路径完成查询。
    0 0
滑动查看更多
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题