MySQL表损坏时SHOW TABLE STATUS显示crashed或Engine变为MyISAM，表明自动修复失败；MyISAM表可用myisamchk -r -f修复，InnoDB表应优先备份还原或启用innodb_force_recovery导出数据。
MySQL 表损坏时 SHOW TABLE STATUS 显示 crashed 或 repairing
表损坏最直接的信号，就是执行 SHOW TABLE STATUS LIKE 'table_name' 时，Comment 列出现 crashed，或 Engine 列变成 MyISAM（即使你用的是 InnoDB）——这说明 MySQL 已自动降级尝试修复，但失败了。
此时不能直接写入或查询该表，SELECT 可能报错 Table './db/table_name' is marked as crashed and should be repaired。
实操建议：
- 先停掉对应网站或应用，避免并发写入加重损坏
- 确认引擎类型：
SHOW CREATE TABLE `table_name`，InnoDB 表一般不适用myisamchk，别误操作 - 对 MyISAM 表，进数据库目录（如
/www/wwwroot/site.com对应的数据库路径在/www/server/data/数据库名/），运行：myisamchk -r -f /www/server/data/数据库名/table_name.MYI
- 对 InnoDB 表，不要手动修文件；优先尝试
REPAIR TABLE table_name（仅部分旧版本支持），更稳妥的是从备份还原，或启用innodb_force_recovery导出数据
宝塔面板里执行 mysqlcheck 命令总提示 Access denied
宝塔默认 MySQL 用户是 root，但密码不一定和面板登录密码一致，而是存储在 /www/server/mysql/etc/my.cnf 的 password 字段，或由宝塔生成并记录在 /www/server/panel/vhost/mysql.conf（新版可能不存明文）。
实操建议：
- 查真实 root 密码：
cat /www/server/mysql/etc/my.cnf | grep password，若为空或乱码，改用宝塔内置命令：/www/server/mysql/bin/mysql -uroot -p$(cat /www/server/mysql/version) -e "SELECT 1"（实际密码常藏在/www/server/mysql/version文件内容里） - 用完整凭证执行检查：
mysqlcheck -uroot -p'你的密码' --auto-repair --optimize 数据库名
- 加
--databases可批量处理多个库，但别加--all-databases，系统库（如mysql、information_schema）损坏风险高，需单独评估 - 如果仍报权限错，可能是 socket 路径不对，加
-S /tmp/mysql.sock指定（路径可通过ps aux | grep mysql查--socket=参数）
备份还原时发现 .sql 文件导入失败，报错 Unknown collation: 'utf8mb4_0900_ai_ci'
这是典型版本 mismatch：备份是从 MySQL 8.0+ 导出的（默认用 utf8mb4_0900_ai_ci 排序规则），但目标环境是 MySQL 5.6/5.7，不识别这个新 collation。
实操建议：
- 不用硬改整个 SQL 文件，临时跳过校验更安全：
mysql -uroot -p'密码' --default-character-set=utf8mb4 数据库名 < backup.sql
，同时确保客户端和服务端都设为utf8mb4 - 如果报错卡在某一行，用
sed快速替换（仅限非生产环境快速救急）：sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' backup.sql
- 长期方案：升级目标 MySQL 到 8.0+，或导出时加参数规避：
mysqldump --compatible=mysql40 --default-character-set=utf8 ...
- 注意：
utf8mb4_unicode_ci和utf8mb4_0900_ai_ci在大小写和重音处理上有差异，业务对排序敏感时，得测具体字段行为
修复后网站仍 500 或查不到数据，检查 ibdata1 和 ib_logfile* 文件状态
InnoDB 引擎的核心文件不是单个表文件，而是共享表空间 ibdata1 加事务日志 ib_logfile0/1。如果这些文件损坏或版本不匹配，即使单表修复成功，MySQL 也可能启动失败或数据不一致。
实操建议：
- 看错误日志定位：
tail -n 50 /www/server/mysql/logs/error.log，重点搜InnoDB、ibdata、log file size - 若提示
The log file size in the .cnf file is different，说明my.cnf里innodb_log_file_size和当前文件实际大小不符，必须停库、删旧日志、再启服务让 MySQL 重建（删前确认无未提交事务） -
ibdata1损坏几乎无法修复，唯一可靠方式是：用最近全量备份 + binlog 增量恢复；没备份就只能尝试innodb_force_recovery级别 1–6 逐步导出还能读的数据 - 宝塔用户容易忽略一点：重启 MySQL 后，要进「软件商店」→「MySQL」→「设置」→「重启」，而不是只用
systemctl restart mysqld，否则宝塔可能没同步状态
真正麻烦的从来不是某条命令敲不对，而是损坏发生在 ibdata1 或 binlog 断点处——这时候没有备份，基本等于数据不可逆丢失。
