目前这个客户说系统有些慢，公司让我去客户哪边解决下，经过综合分析，最后得查到是对接的第三方数据库数据量过大导致的。
目前涉及到数据量过大的数据表有
- 以上数据表都是过亿级别的数据表，已经影响到平台的正常使用，所以建议考虑做分区处理，分区后的数据以单独的数据块存放，解决磁盘I/O瓶颈，提高磁盘的读写能力，增加MySql的性能
分区设计
- 时间阀值需求，指标明细保留90天，趋势数据保留3年
- 监控的指标数据需要能查询90天内的明细，所以原始明细数据保留90天，指标多及监控间隔时间短，必然产生大量的数据
- 每天一个分区存储原始数据
- 统计趋势数据，及删除超过90天的明细数据
- 数据表分区规划示意图
实施
- 通过定时器触发分区函数，首先检查分区是否已经存在，如果不存在则创建，同时检查过期数据，如果不在保留时间阀值内，则删除对应的分区
- 创建分区及删除分区执行流程图
- 涉及到数据库函数为：
- partition_maintenance_all 主要执行入口
- partition_maintenance 主要判断分区是否存在
- partition_verify 判断当前时段内的分区是否存在
- partition_create 创建分区
- partition_drop 删除分区*
- 分区创建后，跟进分区及分区数据是否正常
- 常用语句
-- 查看数据表创建语句，其中带有分区信息
show create table 数据表名称
-- 转换时间戳格式
select (FROM_UNIXTIME(1638374400, '%Y-%m-%d %H:%i:%s'));
-- 查询某个分区数据量
select count(*) from history PARTITION(分区名称);
-- 查询整个表数据量，统计全部分区的数据量
select sum(table_rows) from information_schema.`PARTITIONS` where table_name='数据表名称';- 如果分区、数据正常，则表示数据表分区功能实施完成
目前该方案已经部署在客户生产环境，从目前运行情况来看，没有发现什么问题，性能明显提高很多，如果大家在设计或部署的时候遇到问题，请留言交流。
喜欢的朋友记得给个关注~
评论（0）