应优先比对源库和目标库的information_schema.tables结果，确认表数量及表名是否一致，再排查导出遗漏、权限不足或对象类型混淆等问题。
直接查 information_schema.tables 比表名清单
表数量不一致，第一反应不是“少了哪张表”，而是先确认双方到底有多少张表、哪些表名真正存在。别信目录或备份文件列表，information_schema.tables才是唯一可信来源。
在源库和目标库分别执行：
SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db_name' ORDER BY table_name;
把结果导出为文本，用 diff 或 VS Code 的 compare files 功能比对。注意三点：
-
table_schema名必须完全一致（大小写敏感，尤其在 Linux 下） - 排除系统表：加
AND table_type = 'BASE TABLE'，过滤掉 VIEW、TEMPORARY 表 - 某些工具（如 mysqldump）默认跳过
mysql、performance_schema等系统库，迁移时若没显式指定--databases，容易漏掉业务库以外的自定义库
检查 mysqldump 是否漏导了库或表
如果迁移是用 mysqldump 做的，表数量不一致大概率是导出阶段就丢了。常见漏导场景：
- 没加
--databases，只写了mysqldump db1 db2，但实际命令里漏了一个库名 - 用了
--ignore-table=db.table1却忘了自己加过这条参数，导致某张表被静默跳过 - 导出时加了
--where="1=0"或条件过滤（比如只导某时间范围），但没意识到这会整表跳过 - 目标库导入前没创建对应 database，
mysqldump生成的 SQL 里虽有CREATE DATABASE，但若加了--skip-create-db就不会执行
验证方法：打开 dump 文件，搜 CREATE TABLE 或 INSERT INTO，看是否真有缺失表的语句；再搜 USE `xxx`，确认每个库是否都被显式切换过。
留意视图、临时表、分区表是否被误判
有些“表”在 information_schema.tables 里存在，但不是真实数据表，迁移工具通常不处理它们：
-
VIEW：mysqldump默认不导视图结构，除非加--no-create-info+--routines，否则目标库只有空壳 -
TEMPORARY TABLE：只存在于会话中，information_schema不显示，但某些监控脚本可能误采 - 分区表：MySQL 8.0+ 分区信息存于
INFORMATION_SCHEMA.PARTITIONS，mysqldump会导出完整建表语句，但若目标库版本低于源库（如 5.7 → 8.0），分区语法不兼容，建表失败，表就没了
查清类型最稳的方式是加一列 table_type：
SELECT table_name, table_type FROM information_schema.tables WHERE table_schema = 'your_db_name';
看到 VIEW 或 SYSTEM VIEW 就别拿它当普通表去比数量。
权限不足导致部分表不可见
如果校验账号在目标库权限受限，information_schema.tables 里可能只列出该用户有 SELECT 权限的表，造成“数量变少”的假象。
执行以下命令确认当前用户能看见多少表：
SHOW GRANTS;
重点看是否有 GRANT SELECT ON `db_name`.*。若只有 GRANT SELECT ON `db_name`.`t1` 这种单表授权，那其他表根本不会出现在查询结果里。
修复方式很简单：换一个高权限账号（如 root 或专用校验账号），或给当前账号补授权：
GRANT SELECT ON `your_db_name`.* TO 'check_user'@'%';
表数量差异往往藏在导出逻辑、权限边界或对象类型混淆里，而不是数据丢了。先让两边的 information_schema 查询结果可比，再逐项归因，比盲目重导快得多。
