为数据库服创建备份恢复计划 使用python shell SQL存储过程实现 1制定数据的生命周期 2 数据库每（小时，天或周）做一个完整备份（取决于数据量的大小，和数据的重要性） 3 数据库在两个完整备份之间作增量备份 4 定期把数据库的最新，和此最新的备份拷贝到备用服务器做恢复测试确保数据库的备份文件可以正常恢复。 5 制定数据库备份失败机制（例如备份失败 会重新备份，并把错误信息通过邮件发送给相关DBA， 6 监控数据库自身健康数据（cpu 硬盘，内存）并设置安全阀值，如果超过预警值，会给响应的DBA 发邮件 7 把过期数据迁移到备份服务器

如何把IPv6 的IP地址存入SQL Server 数据库 同时实支持 针对IPv6 的精确查询，模糊查询，IP段查询 问题 1 IPv6 的IP地址有完整的IP地址， 和缩写的IP地址，如果直接入库的话后续针对IP地址的数据分析，和查询会有额外的数据操作。 2 IPv4 有成熟的函数可以把IP地址转换成长整型数 bigint 存储到数据库，同时也支持精确查询和模糊查询。但是在当时IPv6 还没有这样的函数。 解决问题： 1 IPv6 数据库地址在入库前全部转成完整的IP地址 2 写入数据库（SQL Server) 前把完整的IP地址（字符）转换成二进制数据（binary）然后存储到数据库 binary 在SQL Server 数据库中处理速度比字符快了很多，而且支持IP 地址的 精确查询，模糊查询， IP段查询。 3 全段查询时，也要把UI上获取的IPv6 的IP 地址转换成完整的IP地址字符串并转换成 binary 再做查询（后期数据库自定义了一个函数作为转换）

提高后台数据库性能以及处理并发的能力： 当前数据库功能 1 应用程序采集的数据 入库 2 定时对入库的数据进行数据分析 3 为前端提供数据 问题表现 前台查询数据延迟高，后台数据也不能及时的写入数据库，数据库偶尔还会伴随死锁，超长运行时间的SQL 语句，频繁出现。 问题分析结果发现数据库有如下问题 1前端读取数据 1> 前端直接读的表和后台入库的数据在一起，造成 读取和写入相互影响。 2> 前端读取获取数据方式不当（在获取大量数据时，返回数据的数据量设置不合理（太小会造成访问数据太频繁，太大会给数据库造成额外压力） 3> 数据入库，数据库数据处理，前端读取数据 逻辑混乱，数据库中存在大量没必要的重复数据， 重复的数据操作。 4> 数据库备份机制设置不合理，造成数据库备份时会阻塞数据处理。 5> 大量的性能低的SQL 调用（例如 数据逻辑相同的情况下，在循环100次调用SQL语句，取100条数据。 做出的修改 1 把数据数据分为热数据和冷数据，热数据指的是延迟要求高，增删改的频率高，反之则为冷数据比如 日志数据，冷数据用批量入库。热数据写入数据缓存模块（Redis,ES) 。 这样减少了冷数据对热数据的干扰。批量入库也提高了冷数据的处理效率。 2 新增ETL 数据处理模块, ETL 模块作用 1> 会针对业务需求清洗组织数据. 2> 并且会为前端预先计算出一些数据（日报数据， 周报数据）这样前端可以直接获得，不用再取历史数据中查找计算 提高数据查询效率 3> 全局统筹处理数据，避免数据库的重复操作和无效数据，删除重复的数据。 4> 重新创建数据库备份恢复计划 1 确保数据库备份不会阻塞正常的数据处理 2 全量备份和增量备份结合使用，定期检查数据备份文件的可用性。 3 设置数据生命周期，把过期的数据从主数据库服务器迁移到其他的数据备份服务器 5> 组织应用组成员开会 分析讨论 创建数据词典，制定SQL 语句的标准。并针对 应用组提交的SQL 作必要的审核。定期检查数据库中不良SQL（比如 运行时间过长，调用频率过高） 6> 引入MySQL 集群提高数据库并发处理能力