查不到数据主因是库表不匹配或大小写敏感：先用select database()确认当前库，show tables in mydb显式查表，describe mydb.users带库名查结构，并检查lower_case_table_names值。
查不到数据？先确认 USE 和 SELECT 的库表是否匹配
迁移后最常见的情况是：命令行能连上，SHOW DATABASES 看得到库，但一执行 SELECT * FROM user 就报 Table 'xxx.user' doesn't exist。这不是数据丢了，而是当前没选对库，或者表名大小写不一致（尤其从 Windows 迁到 Linux 时）。MySQL 默认在 Linux 下区分表名大小写，而 lower_case_table_names=0 时，建表用的 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_format（8.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）。这个坑和表本身字符集无关，纯属会话层“翻译错误”。
- 连接后立即执行
SET NAMES utf8mb4（不是utf8），这是最简单有效的兜底方案 - 检查当前会话变量：
SHOW VARIABLES LIKE 'character_set%'和SHOW VARIABLES LIKE 'collation%'，重点关注character_set_client、character_set_connection、character_set_results是否全为utf8mb4 - 如果用命令行客户端，启动时加参数：
mysql -u root -p --default-character-set=utf8mb4 - 应用连接字符串里必须显式带
?charset=utf8mb4（如 JDBC 的useUnicode=true&characterEncoding=utf8mb4）
小数据量能查，大数据量卡死？别急着优化 SQL，先看 innodb_buffer_pool_size
迁移后跑 SELECT * FROM orders LIMIT 1000 很快，但 LIMIT 100000 直接超时或响应极慢，不是索引问题，很可能是 InnoDB 缓冲池太小，导致大量磁盘随机读。尤其是从低配环境迁到高配，但没调优 MySQL 配置，缓冲池还维持默认的 128MB，面对千万级表就捉襟见肘。
- 查当前值：
SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS mb - 生产环境建议设为物理内存的 50%~75%，但至少不低于 2GB（
SET GLOBAL innodb_buffer_pool_size = 2147483648） - 修改后需重启或在线调整（MySQL 5.7+ 支持动态扩容，但不能缩容）
- 配合看
SHOW ENGINE INNODB STATUS\G中的Buffer pool hit rate，低于 99% 就值得怀疑
真正容易被忽略的是：迁移脚本里用 mysqldump --skip-extended-insert 导出再导入，会导致单条 INSERT 变成多行，极大拖慢导入速度，也影响后续首次查询性能——因为 Buffer Pool 还没热起来，而数据页又分散。这种“看似成功”的迁移，其实埋下了第一次大查询必卡的雷。
