MySQL数据库迁移后如何测试数据可读性_进行简单查询验证

查不到数据主因是库表不匹配或大小写敏感先用SELECT DATABASE()确认当前库SHOW TABLES IN mydb显式查表DESCRIBE mydb.users带库名查结构并检查lower_case_table_names值。查不到数据先确认 USE 和 SELECT 的库表是否匹配迁移后最常见的情况是命令行能连上SHOW DATABASES 看得到库但一执行 SELECT * FROM user 就报 Table xxx.user doesnt exist。这不是数据丢了而是当前没选对库或者表名大小写不一致尤其从 Windows 迁到 Linux 时。MySQL 默认在 Linux 下区分表名大小写而 lower_case_table_names0 时建表用的 User 和查询用的 user 就不是一张表。执行 SELECT DATABASE() 确认当前库别依赖客户端默认库用 SHOW TABLES IN mydb 显式列出目标库下的表比直接 SHOW TABLES 更可靠查表结构用 DESCRIBE mydb.users带上库名避免歧义如果迁移前用了驼峰或大写表名检查目标 MySQL 的 lower_case_table_names 值SELECT lower_case_table_names值为 0 表示严格区分SELECT COUNT(*) 返回 0重点看字符集和行格式兼容性明明 SHOW TABLES 能看到表SELECT COUNT(*) 却返回 0甚至 SELECT * 无报错但空结果——这往往不是逻辑问题而是底层存储层没正确加载。常见于跨版本迁移如 MySQL 5.7 → 8.0或使用了不同 ROW_FORMAT如 COMPRESSED且目标实例未开启对应插件。检查表状态SHOW TABLE STATUS LIKE users重点关注 Rows 字段注意该值是估算不一定准以及 Row_format 和 Create_options对比源库与目标库的 innodb_file_per_table、innodb_file_format8.0 已移除但 5.7 导出的 .ibd 文件若含 Barracuda 格式在旧版本恢复可能失败运行 CHECK TABLE users若返回 status: OK 说明物理结构可读若报 error: Incorrect information in file大概率是页格式或校验不兼容字符集不一致不会导致查不到但会导致 WHERE name 张三 匹配失败——用 SHOW CREATE TABLE users 对比 DEFAULT CHARSET 和字段级 COLLATE中文乱码或 WHERE 查不到立刻核对连接层字符集迁移后 SELECT * 能出数据但中文显示为问号或一堆乱码或者 WHERE name 李四 查不到八成是客户端连接时没指定字符集走了服务器默认可能是 latin1。这个坑和表本身字符集无关纯属会话层“翻译错误”。 Mokker AI AI产品图添加背景