500万行是初级项目归档启动的实测阈值，因B+树高度增加、buffer pool命中率下滑、DDL耗时剧增三类连锁反应在此触发；早于行数的信号包括Data_length超2GB、EXPLAIN显示全表扫描或文件排序、备份超15分钟等。
500万行就是明确的归档启动线，不是建议，是实测阈值。
为什么500万是初级项目的硬分界点
初级项目通常指单机 MySQL、8–16GB 内存、无专职 DBA、应用层 SQL 能力中等的场景。这类环境里，InnoDB 缓冲池往往默认 128MB 或最多配到 2GB，一旦 t_order 或 t_log 这类表突破 500 万行，就容易触发三类连锁反应：
- B+ 树索引高度从 2 层升到 3 层，
WHERE user_id = ? AND create_time > ?这类常见查询的回表延迟翻倍 - buffer pool 命中率开始滑坡——实测 600 万行时，热点数据（近7天）只占全表 8%，但冷页频繁换入，命中率从 98% 掉到 91%
- DDL 操作（比如加个
status字段）耗时从秒级跳到分钟级，且会锁表或引发主从延迟，初级项目根本扛不住
别等“慢了再动”，先看这三条信号
比数行数更早暴露问题的是这些现象，出现任意一条就得立刻启动归档评估：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
SHOW TABLE STATUS LIKE 't_order'返回的Data_length超过 2GB，哪怕行数才 400 万（说明单条记录大，比如含TEXT字段） -
EXPLAIN显示type是ALL或Extra出现Using filesort，且rows估算值远高于实际返回（比如查 10 条却扫 50 万行） - 备份时间超过 15 分钟，或
mysqldump过程中出现MySQL server has gone away错误
归档方案选型：别一上来就写存储过程
初级项目最常踩的坑，是把归档当成“写个脚本删旧数据”。真正可落地的归档必须满足：不丢、不重、可中断、不影响线上读写。推荐按这个顺序尝试：
- 优先用
ALTER TABLE ... DROP PARTITION——如果表已建为 RANGE 分区（按create_time），删一个月分区是毫秒级的，且空间立即释放 - 次选用
INSERT INTO archive_table SELECT ... FROM main_table WHERE ... LIMIT 10000+DELETE分批搬运，每批必须用事务包住，且WHERE条件必须走索引（比如id BETWEEN ? AND ?） - 慎用存储过程：虽然能封装逻辑，但初级项目往往缺乏异常处理（比如
SQLSTATE 'HY000'没捕获）、没设max_sp_recursion_depth，跑一半卡死就只能 kill 进程
归档最难的从来不是搬数据，而是确认“哪天的数据算冷”——业务方说“三个月前”，但财务对账可能要查半年，法务审计要求保留两年。这个边界没对齐，后面所有技术动作都白搭。
