执行 DELETE 或 DROP 前应设 export MYSQL_HISTFILE=/dev/null 临时禁用历史记录，或改用 mysql -e "SQL" 方式执行，避免敏感操作明文留存于 ~/.mysql_history。
mysql 命令行里执行 DELETE 或 DROP 时，怎么避免被记进 ~/.mysql_history
默认情况下，所有交互式输入的 SQL 命令（包括带密码的连接命令）都会明文写入 ~/.mysql_history，敏感操作一旦误留，后续被他人或自动化工具读取风险极高。
- 最直接的办法是临时禁用历史记录：启动 mysql 客户端时加
--no-defaults并配合mysql --defaults-file=/dev/null -u user -p，这样跳过所有配置文件（包括可能启用 history 的设置） - 更稳妥的是在连接前清空或重定向历史：执行
export MYSQL_HISTFILE=/dev/null，之后该终端下所有 mysql 会话都不会写入历史 - 注意：如果用了
mysql_config_editor存了登录路径，它生成的~/.mylogin.cnf不受MYSQL_HISTFILE影响，但也不会记录 SQL 命令 —— 它只存认证信息，这点常被混淆
用 mysql 连接时，--ssl-mode=REQUIRED 和 --ssl 有啥区别
这两个参数看着像，实际行为差异很大，错用会导致连接看似成功、实则未加密。
-
--ssl是旧版布尔开关，仅表示“尝试启用 SSL”，但服务端不强制时仍会降级为非加密连接，且不校验证书 -
--ssl-mode=REQUIRED是 8.0+ 推荐方式，明确要求加密通道，但依然不校验服务端证书；若要校验，得配--ssl-mode=VERIFY_CA或VERIFY_IDENTITY - 常见错误：脚本里写了
--ssl就以为安全了，结果服务端require_secure_transport=OFF，连接全程走明文
执行高危语句前，如何确认当前连接是否真的走 SSL
不能只看命令行参数，得查运行时状态。MySQL 客户端本身不提供直观提示，得靠查询服务端变量。
- 连接后立刻执行
SELECT * FROM performance_schema.status_by_thread WHERE VARIABLE_NAME = 'Ssl_cipher';，若返回空或Ssl_cipher值为空字符串，说明没走 SSL - 更简单的方式是查
STATUS：运行\s（mysql 客户端命令），在输出里找SSL:行 —— 注意它显示的是服务端反馈，不是客户端意愿 - 容易踩的坑：有些代理（如某些云数据库中间件）会终止 SSL 并重连后端，此时客户端看到的是“SSL: Cipher in use is ...”，但流量到真正 MySQL 实例前已解密
为什么用 mysql_config_editor 存密码后，~/.mysql_history 还是可能泄露敏感操作
因为 mysql_config_editor 只解决“怎么连”，不解决“连上后干了什么”。历史文件记录的是你在 mysql> 提示符下敲的每一条 SQL。
- 即使连接命令里没出现密码（靠
login-path自动填充），你手敲的DROP TABLE users;依然会原样进~/.mysql_history - 想彻底规避，要么用
MYSQL_HISTFILE=/dev/null（推荐），要么改用脚本 +mysql -e "SQL"方式执行，后者默认不记历史（除非显式配置了histignore类选项） - 还有一点常被忽略：如果你在 shell 历史中执行过
mysql -u root -p -e "DELETE..."，那密码和 SQL 都会留在~/.bash_history里 —— 这比 mysql 自己的历史更危险
