mysqlcheck 不能直接做安全基线检查，它仅用于表维护（如检查损坏、修复索引、优化碎片），无法检测密码策略、用户权限、插件配置等安全项。
mysqlcheck 能不能直接做安全基线检查
mysqlcheck 本质是表维护工具，不是安全审计工具。它能检查表结构损坏、修复索引、优化碎片，但对「root 是否无密码」「用户是否绑定 localhost」「plugin 是否为 mysql_native_password」这类安全配置毫无感知。
常见错误现象：mysqlcheck -u root --all-databases --check 执行完显示“OK”，就以为数据库“安全了”——其实只是表没坏，和基线无关。
使用场景仅限于：运维巡检时顺带确认数据一致性，或迁移前验证表状态。别把它当 lynis 或 mysql-audit 用。
- 它不读取
my.cnf配置项，也不连接 MySQL 服务端查information_schema或mysql.user - 它无法检测弱密码、空密码、通配符主机（
'%'@'%'）、多余管理员账号 - 执行时若用户权限不足（比如没
PROCESS或SELECT权限），会静默跳过或报错Access denied，容易误判
真正有效的 MySQL 安全基线检查怎么做
必须组合三类动作：配置文件扫描 + 运行时 SQL 查询 + 系统层权限校验。没有单命令能覆盖全部。
实操建议分步来：
- 查配置文件：用
grep扫描/etc/my.cnf、/etc/mysql/my.cnf、/usr/my.cnf中关键项，例如skip_networking、bind_address、require_secure_transport - 连库查用户：用高权限账号执行
SELECT user,host,plugin,authentication_string FROM mysql.user WHERE account_locked='Y'，重点看plugin是不是caching_sha2_password（新版默认）但客户端不兼容，或auth_socket是否被误用于远程 - 查权限分配：运行
SELECT * FROM mysql.db WHERE user!='' AND host='%'，确认有没有数据库级授权放给通配符主机 - 系统层检查：确认
mysqld进程是否以非root用户运行（ps aux | grep mysqld），数据目录权限是否为750且属主是mysql:mysql
有哪些轻量又靠谱的开源审计工具可替代手动检查
如果不想写一堆 SELECT 和 grep，推荐两个真正在生产环境跑过的工具：一个是 mysql-audit（Percona 提供），另一个是 mysql-security-check（GitHub 上小而专的 Python 脚本）。
它们的区别很实际：
-
mysql-audit基于 Percona Server 或 MySQL 8.0+ 的企业审计插件，需先启用audit_log插件，然后用配套脚本解析日志 —— 适合已有审计日志体系的环境，但普通社区版 MySQL 默认不带该插件 -
mysql-security-check直接连库执行预设 SQL 清单（比如查空密码、匿名用户、过期密码策略），输出带风险等级的 Markdown 报告，支持--dry-run预览，参数少、无依赖，适合快速摸底 - 注意：所有工具都依赖你提供的账号有足够权限（至少
SELECTonmysql.*），否则会漏检；别用debian-sys-maint这类系统账号跑，它权限过大且配置常被忽略更新
最容易被忽略的三个基线细节
很多团队扫完配置、查完用户就交差，结果上线后出问题。真正卡脖子的往往是这三点：
-
default_authentication_plugin在my.cnf里设成caching_sha2_password，但应用用的是老版本 Connector/J 5.x，连接直接失败 —— 不是不安全，而是不兼容 - MySQL 8.0+ 默认开启
caching_sha2_password，但mysql.user表里旧账号仍用mysql_native_password，审计工具可能只报“插件不统一”，却不提示“新用户无法登录” -
bind_address = 127.0.0.1看似安全，但如果容器化部署且network_mode: host，这个绑定等于没绑 —— 基线检查得结合部署形态看，不能只信配置字面值
安全基线不是 checklist 打钩游戏，是配置、代码、部署三者咬合的结果。少看一眼 my.cnf，多查一行 docker inspect，差别就在那儿。
