时间：2021-07-01 10:21:17 帮助过：13人阅读
可以看到RDS已经具备相当丰富的自动化数据库运维的功能，用户不用太关心后端数据库的运维，以前这些非常专业的DBA工作完完全全可以交由RDS系统来完成，那么还需要用户做什么，是不是不需要用户干预了？答案是需要的，在日常的工单问题发现：
一． 经常会发现由于自己的开发人员误操作导致用户数据被误删除，虽然RDS支持恢复到任意时间点，但毕竟需要时间去恢复，会造成对用户的影响；所以线上的操作务必谨慎，必须在测试环境中完全验证后才能到线上执行，同时需要必要的数据备份；
二．开发人员发布了一个新功能，但是新功能中的一条sql语句没有添加索引，导致了全表扫描，RDS的CPU，IO达到100%，影响了整个应用的响应时间；所以新发布的任何sql都必须进过严格的审核，添加上必要的索引；
三． 开发人员在业务高峰期对表进行一个表添加索引或者添加字段的操作（删除数据），导致该表的其他访问堵塞，影响前端应用；所以任何的线上操作都需要在业务的低峰期进行，生产变更必须严格控制在可允许的变更窗口内；
四．RDS实例由于时间到期后没有及时进行处理，导致实例被锁定或者释放，虽然最终数据可以恢复回来，但这种故障的发生往往令人心惊胆寒；
所以需要用户制定出合理的流程规范来使用RDS，比如设计开发过程中的数据库流程规范，线下测试环境与线上生产环境数据的导入导出流程规范，线上数据订正的流程规范，线上数据库操作（添加字段，添加索引）的流程规范，数据库上线下线的流程规范。
在阿里巴巴数据库技术团队，即使有了非常自动化的运维平台，上述的这些流程制定也是开发，测试，DBA都必须遵守的，就是因为有了上述的这些流程才避免了很多不必要的故障发生，大大提高了整个平台的稳定性，除此之外还制定了运维红线：
一．禁止在非变更窗口执行变更：
.所有的变更必须提前4小时提交申请，进过审批后才能执行操作；
.全网变更必须经过线下测试，线上小规模验证后，才能全网推送；
.重大变更（数据库停机，扩容，迁移）必须团队review；
.数据订正和数据提取必须经过团队leader审核通过后才能进行操作；
二．安全保密：
.禁止未经正式审批进行查阅，变更，传播，移动线上数据；
.禁止对无关人员提供系统登录和发布权限；
数据库开发规范：赶集网（国内互联网公司）的DBA 吴诗展把自己多年的数据库mysql运维开发检验总结了—MySQL数据库开发的三十六条军,对于很多的RDS用户来说同样是很受用的，包括了：基本军规，字段军规，索引军规，SQL类军规，约定类军规，在此也很感谢他能够把多年来的经验总结分享给众多的数据库用户，在这里也在着重强调一些比较重要的规范：
一．表主键的设置：自增主键是你的最佳选择
.在设计表的时候默认都添加一列无业务意义的自增id的主键：id bigint not null auto_increment；
.自增型主键以利于插入性能的提高
.自增型主键设计(int,bigint)可以降低二级索引的空间，提升二级索引的内存命中率；
.自增型的主键可以减小page的碎片，提升空间和内存的使用；
.无主键的表删除，更新在row模式的主从架构，会导致备库hang住；
可参考：mysql主键的缺少导致备库hang
二.引擎选择：INNODB 引擎是你的最佳选择
使用INNODB存储引擎还是Myisam存储引擎？
.RDS的内存配置innodb的innodb_buffer_pool_size,Myisam的key_cache配置32k；
.主机断电，crash后Myisam表容易出现索引坏叶，需要手工repair修复索引；
.Myisam存储引擎的表备份时候会被全局锁住，导致无法写入数据；
案例一:下面的这幅图片就是myisam引擎的表由于一个大查询堵塞了该表的其他更新：
案例二：.FEDERATED 存储引擎使用存在bug，会导致备份失败
error log: >> log scanned up to (867972807) 130616 00:00:58 innobackupex-1.5.1: Continuing after ibbackup has suspended 130616 00:00:58 innobackupex-1.5.1: Starting mysql with options: –defaults-file=’/etc/my3015.cnf’ –password=xxxxxxxx –user=’Xtrabak’ –host=’127.0.0.1′ –port=’3015′ –unbuffered – 130616 00:00:58 innobackupex-1.5.1: Connected to database with mysql child process (pid=31437) 130616 00:01:00 innobackupex-1.5.1: Starting to lock all tables… >> log scanned up to (867972807) innobackupex-1.5.1: Error: mysql child process has died: ERROR 1160 (08S01) at line 7: Got an error writing communication packets while waiting for reply to MySQL request: ‘FLUSH TABLES WITH READ LOCK;’ at /usr/bin/innobackupex-1.5.1 line 381. 2013-06-16 00:01:06 [info]: Xtrabackup error,you can get detail from Logfile. 2013-06-16 00:01:06 [info]: ====================================== All backup finished . |
三.索引设计误区:
误区案例一：对查询条件的每个字段建立单列索引
SQL查询：
SELECT count(*) FROM order o WHERE is_send=0 AND
o.order_status in (0,1) AND o.shipping_status = 0 AND
o.is_separate > 0 and o.is_yushou=0 and o.sd_id=23
and o.add_time>= ’1370246433′ and o.add_time<= ’1370332842′
and o.jhd_id=0 group by o.order_id;
KEY：该表有近30个索引
PRIMARY KEY (order_id), UNIQUE KEY order_sn (order_sn), UNIQUE KEY deal_code (deal_code), KEY ind_user_id (user_id), KEY ind_shipping_id (shipping_id), KEY ind_pay_id (pay_id), KEY ind_agency_id (agency_id), KEY ind_extension_id (extension_id) , KEY ind_order_id (order_id), KEY ind_delivery_time (delivery_time) , KEY ind_invoice_no (invoice_no), KEY ind_user_nick (user_nick), KEY idx_cz_shipping_fee (cz_shipping_fee), KEY ind_mobile (mobile), KEY ind_order_info_sd (sd_id,is_send,add_time), KEY ind_order_info_status (shipping_status), KEY ind_order_pay_status (pay_status), KEY ind_order_is_yushou (is_yushou), KEY ind_order_dist_type (dist_type), KEY ind_order_jhd_id (jhd_id), KEY ind_order_is_send (is_send), KEY ind_order_ck_id(ck_id ), KEY ind_order_is_separate(is_separate), KEY ind_consignee (consignee), KEY ind_order_info_lylx (lylx,order_status,is_send); |
索引设计误区二：对查询的所有字段建立组合索引
09:44:03> show table status like ‘order’/G; *************************** 1. row *************************** Name: order Engine: InnoDB Version: 10 Row_format: Compact Rows: 5708209 Avg_row_length: 357 Data_length: 2042626048 Max_data_length: 0 Index_length: 9014607872 Data_free: 5242880 Auto_increment: NULL Create_time: 2013-04-09 22:56:57 Update_time: NULL Check_time: NULL Collation: utf8_bin Checksum: NULL Create_options: omment:订单表 该表的数据只有2G，但是索引却占用了9个G： |
KEY `idx_plt_taobao_order_dp_id` (`dp_id`,`customerno`,`created`,`endtime`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`ccms_order_status`) KEY `idx_plt_taobao_order_created` (`created`,`customerno`,`endtime`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`) KEY `idx_plt_taobao_order_endtime` (`endtime`,`customerno`,`created`,`pay_time`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`) KEY `idx_plt_taobao_order_pay_time` (`pay_time`,`customerno`,`created`,`endtime`,`modified`,`consign_time`,`payment`,`status`,`type`,`total_fee`,`refund_fee`,`num`,`received_payment`,`trade_from`,`dp_id`,`ccms_order_status`) |
希望这篇blog能够对你使用RDS有所帮助.