数据库运维究竟需要做什么?
数据库是存放数据、经常是那些高敏感度数据的宝库，因此它也毫无疑问的是合规检查程序的重点区域。几乎所有的企业合规都会对哪些人、能在什么时间、访问什么数据库作出规定，并且需要一个专职人员来管理这些权限。那么，作为管理数据库的专职人员，需要做些什么呢？下面来了解一下~
一.数据库生命周期
结合软件生命周期、项目的开展，数据库的生命周期，大致可分为这么几个阶段。
1.规划
在立项后，对于数据库平台的软硬件选型，以及大致的数据库架构。
（1）配置多少台服务器，服务器的内存大小/磁盘空间、IOPS/CPU核数/网络带宽等；
（2）选择的操作系统与数据库产品，及相应版本；
（3）整体架构，比如是否考虑：HA,Scaleout,loadbalance,读写分离等策略。
2.开发
开发的工作，通常是在测试环境上进行的，开发结束后搬到生产环境。
（1）数据库设计；
（2）SQL编程及调试；
（3）开发过程中的SQL优化。
3.实施
开发的数据库程序到生产环境的部署。到这里，基本是项目上线了。后面就进入了运维阶段。
二.运维做些什么
从上面的图来看，运维是项目上线后的工作。看看从项目上线开始，运维都做了什么。
1.部署环境
（1）数据库安装（如果服务器太多，可以选择静默安装）；
（2）参数配置（实例、数据库参数）；
（3）权限分配（登录、数据库用户权限）。
2.备份/还原
对于数据库来说，有个可用的备份是非常重要的，防止有数据损坏，用户误操作等造成的数据丢失。保证了数据的存在，运维才有意义，否则其他工作做的再好也是白搭。
3.监控
对于运维来说，首先要保证数据库的运行，然后就是运行中系统的性能。所以监控主要分为这两点：
（1）数据库运行状态，有没有什么数据库中断或异常、错误或警告？
（2）数据库性能，有没有什么性能问题或者性能隐患？
4.故障处理
在监控过程中发现，或者系统用户反馈出来的数据库错误或者警告，进行诊断并修复。
5.性能优化
在监控过程中发现，或者系统用户反馈出来的数据库性能问题，进行优化。
6.容灾
容灾只是手段，最终还是为了保证系统的可用性，通常选择的策略有：故障转移集群、镜像、日志传送、异地备份等。
如果在实施时，已经部署了容灾策略，那么这时只要做一些状态监视即可。
也有系统是在上线一段时间之后，才补充部署容灾策略的。
7.升级/迁移
（1）升级
通常是在本机进行，硬件不变，比如：更换操作系统、数据库的版本、打补丁；
（2）迁移
通常是需要升级硬件，比如：更换新的服务器，所以把数据库搬到新的服务器上；
也有在本机“迁移”，只是为了移动数据库文件的位置。
（3）迁移+升级
不过很多时候，都是在迁移中做升级，也就是换了新的服务器，也换了软件版本。
8.健康检查
通常叫做巡检或者HealthCheck。可能是每天、每月、每年的。
事实上如果把巡检的内容做到每天、每小时、甚至每X分钟，那就是一个准实时的系统监控。
9.系统用户反馈的数据库问题
用户反馈出来的任何数据库问题，需要DBA去做处理，即便有时诊断出来并非数据库的问题。
从广义上来看，除去数据库开发外的其他任务，都应该算在运维职责之内。
问：那么数据库运维到底都有哪些日常任务？
答：把上面的每项任务要做的事情一个个罗列出来就可以了。
比如，数据库运行状态监控包括：数据库服务是否中断、磁盘空间、错误日志检查、数据库一致性检查、作业运行状态、索引碎片检查等等。
后面会逐个分解各项任务的详细清单。
二、数据库运维工作总原则
1、能不给数据库做的事情不要给数据库，数据库只做数据容器。
2、对于数据库的变更必须有记录，可以回滚。
三、权限相关
总原则，以最低粒度控制权限。
SELECT权限：所有开发人员均可拥有自己业务范围内的表权限。
INSERT/UPDATE/DELETE权限：所有项目经理可以拥有自己业务范围内的表权限。
Structure权限：数据库管理员可以拥有。
Administration权限：系统管理员和数据库管理员可以拥有。
程序访问权限：根据IP和系统名建立用户名，只拥有必须表的访问权限。
全部权限：技术总监掌管，MySQL系统表mysql表权限除技术总监任何人不得拥有。
权限粒度：开发人员权限粒度到表一级，数据库管理员和系统管理员权限粒度到库一级。
访问限制：除DBA和系统管理员需要24小时保证可以操作数据库外，其他人均需要绑定IP。
密码强度：必须根据目标/来源/用户等信息设置密码，保证不用用户在不同主机从不同来源的密码不一样，每隔一段时间需要集中更换密码。
四、改表相关
总原则，以最少的开销按需记录数据，所有变更要有记录。
#p#分页标题#e#
表结构修改流程：开发人员提交建/改/删表的SQL（必须有注释）给DBA，并且说明建/改/删表原因，DBA审查，与开发人员交流修正，由DBA执行SQL操作，并记录。
表结构改动注意：（越靠前优先级越高）
按需建立字段，不得采用远大于需求的类型。
尽量采用无符号型数据类型。
尽量采用固定长度类型。
尽量避免TEXT类型。
尽量用数字来代替字符。
可以用ENUM枚举数量不多的字符。
如果必须采用TEXT类型，如无特殊情况，必须拆表单独存放TEXT列。
存在必须用函数计算才能做条件的列，新建一存放函数计算结构，对新列进行索引，采用触发器自动更新。
记录修改时间尽量采用时间戳，不要采用时间类型列然后手动设置。
分离表中常用和不常用数据，分开存储。
历史数据要及时分离，按一定规则命名表或存放到数据仓库。
类似标记字段设计要合理，尽量避免在SQL中出现<>，尽量使用>/</=来完成条件查找。
类型选择细则参考已发的类型选择文档。
五、索引相关
总原则，以高并发SQL为核心建立索引，尽量复用索引。除非某个字段经常单独作为查询字段，并且不会作为其他组合索引的第一个列，才为本字段建立单独的索引。
尽可能建组合索引，综合考量涉及的SQL，遵循尽量复用的原则建立索引。
优先处理高并发SQL的索引，很少使用的SQL或者只在闲时使用的SQL可以不为其索引。
小表可以不建立索引（如果参与关联需要为关联字段索引）。
索引后结果集仍较大可以增加排序字段进索引，若执行计划不使用，则删除。
关联字段除特殊情况都需要建索引。
要及时根据SQL的使用情况调整索引。
六、架构相关
总原则，尽可能在内存中完成大部分操作。
内存足够选择InnoDB（高并发数据与内存大小相当），内存不足用MyISAM，归档用Archive，事务相关用InnoDB，临时高并发数据用Memory。
Master-Slave架构，适合明显读大于写的情况。
Master-Master架构，无比使两个Master产生不同的主键，例如一台产生奇数主键，一台产生偶数主键，
单机事务用InnoDB，集群事务用LVS+NDB，切不可直接用NDB，效率极低。
分布式事务尽量避免，如果必须，则采用XA事务，分段提交，或者直接采用NDB集群引擎。
原则上历史数据和生产数据不要放在同一数据库，如历史数据极少使用，则建立新库将历史数据保持表名不变存入，只要USE改变数据库就可以查询历史数据，比较常用的历史数据采用表名+日期来存放相应的历史数据，通过表明和日期拼接来做历史查询。
主库写压力较大时采取级联复制，读库压力更大时采用一对多复制，以平衡压力为目标。
历史数据拆分由DBA与开发人员商议拆分时间，每次拆分时间由DBA与开发人员确认则删除或转移至数据仓库。
七、SQL相关
总原则，最小化查询结果集，不做不必要的操作，分散压力到平时。
尽量不做全表查询，根据需要选择需要的字段需要的行。
条件尽可能详细，不要让数据库扫描不必要的行。
选择条件尽可能按照一致的顺序出现，最大化利用索引。
尽量将大结果集操作拆分到多次执行，避免数据库长时间被锁。
八、工作流程
①通过Cacti和mysqlreport脚本查看运行状态
②通过mystat脚本监控实时状态
③通过mysqlsla脚本分析昨日慢查，可作为计划任务每天定时执行，清空旧慢查
④对每日慢查进行调优
⑤通过mysqlidxchx脚本对无效索引进行检查
⑥建表要询问哪些字段会用来查询和连接，建立索引
⑦改字段要问清类型和范围，设立合适的数据类型
⑧表结构的修改必须加注释，每个字段都要有注释，除了id
⑨从数据库删除数据一定要先备份再删除。
⑩每月末要执行历史数据清理，通过mysqldump–where来导出指定范围的数据，插入数据仓库。
无用表和字段要及时清理
九、运维过程中的问题解决
运维过程中遇到问题时，如果能够通过自己/他人的经验解决，那么固然好；
但如果没有解决思路的话，通常是这样去查：
1.查日志：操作系统/数据库/应用程序日志中，有没有相关的错误/信息提示；
2.查错误号：官方文档/网友分享中，有没有解决方案；
3.如果都没有找到，那么就中奖了，自己分析不出就团队分析，团队分析不出找官方支持，当然有的时候，官方支持也不是一定能解决。
#p#分页标题#e#
注意：对于在线系统，这么慢慢查下去，时间可能消耗太久，会影响用户体验。通常是优先快速解决问题，那怕只是用临时应急方案，以保证系统的可用性，然后再去分析根本原因，彻底解决，以防止下次再发生。
小编结语：
更多内容尽在课课家教育！
