看起来你已经做了不少扎实的基础排查，SELinux、socket权限、编译依赖这些核心点都确认过了，那咱们再从几个容易忽略的角度深挖一下：

• 检查Sysbench的动态库依赖
  有时候编译时明明指定了MySQL 8的库，但运行时系统可能还是优先加载了旧版本的MySQL库。你可以用这条命令查看Sysbench实际依赖的库路径：

  ldd $(which sysbench) | grep mysql
  

  如果输出里的libmysqlclient.so指向的不是/home/mysql8/lib下的文件，那问题根源就在这了。临时解决可以先设置环境变量再测试：

  export LD_LIBRARY_PATH=/home/mysql8/lib:$LD_LIBRARY_PATH
  sysbench ... # 你的测试命令
  

  要是管用，就把这个变量加到你的~/.bashrc或者会话启动脚本里永久生效。

• 明确指定连接参数，排除默认值干扰
  哪怕socket文件权限正常，也有可能Sysbench默认查找的socket路径和MySQL实际路径不匹配。你可以在测试命令里强制指定socket路径：

  sysbench --mysql-socket=/mnt/optane2/mysql.sock --mysql-user=你的用户名 --mysql-password=你的密码 ...
  

  另外，MySQL 8默认用caching_sha2_password认证插件，虽然Sysbench 1.0.14理论上支持，但也可以临时把测试用户改成mysql_native_password认证试试，排除插件兼容性问题：

  ALTER USER '你的用户名'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
  FLUSH PRIVILEGES;
  

• 对比会话环境变量的差异
  你提到PATH里已经包含/home/mysql8/bin，但可以看看有没有其他MySQL相关的环境变量缺失。比如在能正常连接的客户端会话里执行env | grep -E "(MYSQL|LD_LIBRARY)"，然后把这些变量复制到当前会话里导出，再跑Sysbench试试：

  export MYSQL_HOME=/home/mysql8
  export LD_LIBRARY_PATH=/home/mysql8/lib:$LD_LIBRARY_PATH
  

• 开启Sysbench的详细日志定位错误
  加个详细输出参数，看看连接过程中具体哪一步出了问题：

  sysbench --verbosity=4 ... # 你的测试命令
  

  或者用--debug=on获取更细致的调试信息，这样能直接看到是认证失败、库找不到还是连接超时，帮你更快锁定问题。

内容的提问来源于stack exchange，提问作者FrankO