MySQL登录的时候，如果明文指定了密码，在登录成功之后就会抛出下面的警告。
[root@dev01 /]# mysql -uroot -pxxxx
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 2837
不要小看这个错误，有些业务验证是不允许出现Warning的，所以可能有些大厂还需要自己定制一下这个错误的逻辑。
当然如果不需要知道密码，能不能换个方式来做呢，其实也行，在5.6中开始有了loginpath，和Oracle中的钱包的功能差不多，其实就是一种认证，做了授权，你不需要知道这些信息，loginpath就是一道桥梁为你做了认证。
如果你是5.5的版本，没了loginpath，有没有可行的方案来满足需求呢。
有的同学可能这个时候才开始问，需求是什么?
我们设想一下，命令行的方式中，输入明文密码，那还要密码干嘛，干脆我输入密码的时候你别看，但是history命令里面有啊。
所以这也算是一个风险点的入口，如果因为一些意外的情况登录，那么这种情况就很尴尬了。这是需求一。
还有一种场景，如果我们有大量的MySQL环境，每个环境的DBA账户密码是统一的，但是密码很复杂。我们不能输入明文，那么就输入密码格式，那就意味着交互和手动输入，手动输入简直了，你会发现这种操作真是原始，高级一点，用下keypass或者keepass等，这个是依赖于本地的环境配置。所以需求二的特点就是手工维护密码啰嗦，手工输入密码太原始。
那我们写脚本，但是脚本里面的密码还是可见的，调用的明文密码问题解决了，但是内容中的密码还是可读的。
所以这种情况下，一个很自然的方法就是加密。
其中一种是对密码加密，比如我们得到一个密码加密后的串，在需要调用的时候做一下解密，得到真实的密码。这个过程是在脚本里的逻辑来实现，所以我们得到明文密码的概率要低一些。
另外一类就是对文件加密，比如对整个文件加密，加密之后文件就没法读了。所以加密后的密码又被加密了。对文件加密有shell的方式还有Python等语言会
如果要调用脚本的时候，其实就是先解密文件，然后调用解密逻辑，得到真正的密码，然后开启访问的请求。
比如我得到了一个加密后的密码串。调用的解密逻辑是decrypt_passwd,当然这个是可读还可逆的，我们其实可以再加入一些复杂的因子来干扰。
脚本的初步内容如下：
sec_password='RHB6WUF1d1c5TTEzabadfo='
dec_passwd=''
sql_block=''
function decrypt_passwd
{
tmp_passwd=$1
dec_passwd=`echo $tmp_passwd|base64 -d`
}
decrypt_passwd $sec_password
instance_ip=$1
instance_port=$2
port=$1
if [ ! -n "$port" ]; then
echo '############################################'
echo 'Please input correct MySQL Port and try again.'
echo '############################################'
ps -ef|grep mysqld|grep -v grep |grep -v mysqld_safe
exit
fi
/usr/local/mysql/bin/mysql -udba_admin -p$dec_passwd -h127.0.0.1 -P$1
这样一个简单的文件，使用gzexe来加密即可，就是我们初步预期的效果了。
这个文件就类似一个二进制文件，我们拷贝到任何服务器端，指定入口，就可以方便的访问了。
