mysql归档操作通常指将历史数据从业务表迁移到归档表，释放主表存储空间，提升业务查询效率。在执行大批量数据归档时，实时监控进度能让运维人员及时判断任务是否正常推进，避免出现异常中断却未察觉的情况。
通过information_schema系统表监控
mysql的information_schema库中包含大量运行时状态信息，我们可以通过查询PROCESSLIST表获取当前执行的归档相关线程状态，结合INNODB_TRX表查看事务相关的行操作数量，间接判断归档进度。
首先查询当前正在执行的归档线程：
-- 查询包含归档相关关键词的正在执行的线程
SELECT
ID,
USER,
HOST,
DB,
COMMAND,
TIME,
STATE,
INFO
FROM information_schema.PROCESSLIST
WHERE INFO LIKE '%INSERT INTO archive_table%'
OR INFO LIKE '%DELETE FROM business_table%';
如果归档操作使用了事务，还可以查询INNODB_TRX表获取事务相关的行修改数量：
-- 查询当前活跃事务的行操作信息
SELECT
trx_id,
trx_state,
trx_started,
trx_rows_locked,
trx_rows_modified
FROM information_schema.INNODB_TRX
WHERE trx_state = 'RUNNING';
其中trx_rows_modified字段表示当前事务已经修改的行数，结合归档任务预计要处理的总行数，就能大致计算出进度比例。
自定义进度记录表实现精准监控
如果归档操作是自己编写的程序或者存储过程，可以在归档逻辑中插入进度记录的逻辑，将每一步的处理进度写入自定义的进度表，实现更精准的实时监控。
首先创建进度记录表：
-- 创建归档进度记录表
CREATE TABLE archive_progress (
id INT PRIMARY KEY AUTO_INCREMENT,
task_name VARCHAR(50) NOT NULL COMMENT '归档任务名称',
total_rows BIGINT NOT NULL COMMENT '预计处理总条数',
processed_rows BIGINT NOT NULL DEFAULT 0 COMMENT '已处理条数',
progress_rate DECIMAL(5,2) GENERATED ALWAYS AS (processed_rows / total_rows * 100) STORED COMMENT '进度百分比',
status VARCHAR(20) NOT NULL DEFAULT 'RUNNING' COMMENT '任务状态：RUNNING/SUCCESS/FAILED',
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
然后在归档的循环逻辑中，每处理一批数据就更新进度表：
-- 存储过程中的进度更新示例
DELIMITER //
CREATE PROCEDURE archive_data_with_progress()
BEGIN
DECLARE v_total BIGINT;
DECLARE v_processed BIGINT DEFAULT 0;
DECLARE v_batch_size INT DEFAULT 1000;
DECLARE v_task_name VARCHAR(50) DEFAULT 'user_log_archive';
-- 获取需要归档的总条数
SELECT COUNT(*) INTO v_total FROM business_user_log WHERE create_time < '2024-01-01';
-- 插入初始进度记录
INSERT INTO archive_progress (task_name, total_rows, processed_rows, status)
VALUES (v_task_name, v_total, 0, 'RUNNING');
-- 循环处理归档
WHILE v_processed < v_total DO
-- 执行归档逻辑：插入归档表，删除业务表数据
INSERT INTO archive_user_log SELECT * FROM business_user_log
WHERE create_time < '2024-01-01' LIMIT v_batch_size;
DELETE FROM business_user_log
WHERE create_time < '2024-01-01' LIMIT v_batch_size;
-- 更新已处理条数
SET v_processed = v_processed + v_batch_size;
-- 更新进度表
UPDATE archive_progress
SET processed_rows = v_processed
WHERE task_name = v_task_name;
-- 避免锁表时间过长，每次提交后暂停0.1秒
DO SLEEP(0.1);
END WHILE;
-- 更新任务状态为成功
UPDATE archive_progress SET status = 'SUCCESS' WHERE task_name = v_task_name;
END //
DELIMITER ;
执行归档任务后，只需要查询archive_progress表就能实时获取进度：
-- 查询归档进度
SELECT
task_name,
total_rows,
processed_rows,
CONCAT(progress_rate, '%') AS progress,
status,
update_time
FROM archive_progress
WHERE task_name = 'user_log_archive';
通过慢查询日志辅助判断进度
如果归档操作没有自定义进度逻辑，也可以开启mysql的慢查询日志，将归档相关的长查询记录到日志中，通过分析日志中的执行时间、扫描行数等信息，辅助判断归档进度。
首先开启慢查询日志：
-- 开启慢查询日志，设置慢查询阈值为1秒 SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
归档操作执行后，查看慢查询日志，找到对应的归档语句，日志中会记录该语句的执行时间、扫描行数、返回行数等信息，结合多次查询的结果，就能判断归档操作是否在持续推进。
不同监控方式对比
以下是几种监控方式的优缺点对比：
| 监控方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 系统表查询 | 无需修改归档逻辑，开箱即用 | 进度为估算值，不够精准 | 临时执行的归档任务，无自定义逻辑的场景 |
| 自定义进度表 | 进度精准，可记录任务状态 | 需要修改归档逻辑，增加少量开发成本 | 长期运行的归档任务，需要精准监控的场景 |
| 慢查询日志分析 | 无需侵入归档逻辑，可回溯历史 | 实时性较差，需要人工分析日志 | 归档任务出现异常后排查问题的场景 |
注意事项
- 监控归档进度时，尽量避免频繁查询系统表，防止增加数据库额外负载，建议查询间隔设置为1-5秒。
- 如果归档操作涉及大批量数据删除，建议分批执行，每批处理1000-5000条数据，避免长事务锁表影响业务。
- 自定义进度表需要定期清理历史记录，避免进度表数据量过大影响查询效率。