mysqlbug脚本头部硬编码记录原始configure命令，是最直接可靠的获取方式；若不存在，则可能是二进制包或MySQL 5.7+版本未附带该工具。
mysqlbug 里藏了 configure 命令行
绝大多数源码编译安装的 MySQL，其 mysqlbug 脚本头部会硬编码记录当初运行的 configure 命令。这是最直接、最可靠的获取方式，不需要连接数据库，也不依赖权限。
-
mysqlbug文件通常位于 MySQL 安装目录的bin/子目录下，比如/usr/local/mysql/bin/mysqlbug - 执行
grep CONFIGURE_LINE /path/to/mysql/bin/mysqlbug即可提取原始配置参数 - 如果返回空，说明该 MySQL 是二进制分发版（如官方 tarball 或 RPM），
mysqlbug未被保留或未写入 configure 行 - 注意：MySQL 5.7+ 默认不再附带
mysqlbug，尤其官方二进制包几乎都删掉了它
INFO_BIN 文件适用于较新版本（5.5+）
部分较新源码编译版本（尤其是 5.5 及以后）会在 docs/INFO_BIN 中保存构建信息，比 mysqlbug 更完整，含编译器、CFLAGS、特性开关等。
- 路径通常是
$MYSQL_HOME/docs/INFO_BIN，例如/usr/local/mysql/docs/INFO_BIN - 直接
cat即可查看，里面包含CMAKE_BUILD_TYPE、ENABLED_PROFILING、HAVE_OPENSSL等关键布尔标志 - 若该文件不存在，不代表没编译——只是构建时未生成或被清理了；不要误判为二进制包
- 该文件内容是构建时快照，不随运行时配置变化，但无法反映你当前是否启用了某个插件（比如
plugin_load是运行时加载的）
SHOW VARIABLES LIKE 'version_compile%' 只给平台信息
这个 SQL 查询能拿到操作系统和架构标识，但不是真正的编译参数，容易误以为“已经查到了”。
-
SELECT @@version_compile_os, @@version_compile_machine;返回类似Linux和x86_64 - 它不包含
--with-ssl、--with-zlib、-DWITH_INNODB=ON这类决定功能可用性的选项 - 该变量值来自 CMake 缓存或预定义宏，静态写死，连
cmake -LA的输出都比它详细 - 在托管环境（如 AWS RDS、阿里云 PolarDB）中可能不可用，报错
ERROR 1105 (HY000): Unknown error
二进制包基本没戏，别白费劲
官方下载的 mysql-8.0.33-linux-glibc2.17-x86_64.tar.xz 这类包，压根没保留任何 configure 记录。你看到的 mysqld -V 输出只告诉你发行版名称和平台，不是编译参数。
-
mysqld -V输出形如mysqld Ver 8.0.33 for Linux on x86_64 (MySQL Community Server)，仅用于区分社区版/企业版/Percona -
mysql --version或SELECT VERSION()也只返回版本号，不含编译细节 - 想确认是否支持 SSL？直接连上去查
SHOW VARIABLES LIKE 'have_openssl';更实际 - 真要逆向验证编译选项，只能靠
strings /path/to/mysqld | grep -i ssl这类模糊匹配，结果不可靠
真正有用的编译参数，只存在于源码构建过程的残留文件里；一旦缺失，就只能靠功能测试反推，没有捷径。
