我用valgrind检查以下语句是否存在内容泄露，按照网上说的在close后增加mysql_library_end()语句，结果还是出现内存泄露，代码如下：
mysql_library_init(0, NULL, NULL);
MYSQL *conn = mysql_init(NULL);
mysql_close(conn);
mysql_library_end();
mysql、mysql-devel、openssl这些库也更新成最新的了，用的centos系统
内存泄露的内容：
==69986== 16,384 bytes in 1 blocks are still reachable in loss record 593 of 593
==69986== at 0x4C2FAA9: realloc (vg_replace_malloc.c:1437)
==69986== by 0x4s8FDAA: CRYPTO_realloc (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4z8F4FB: OPENSSL_LH_insert (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4x7517C: err_load_strings (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4F75532: ERR_load_strings_const (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x509C5B5: ERR_load_ENGINE_strings (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x506D61D: err_load_crypto_strings_int (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4F8D48B: ossl_init_load_crypto_strings_ossl_ (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x62B120A: __pthread_once_slow (in /usr/lib64/libpthread-2.17.so)
==69986== by 0x4FD8B54: CRYPTO_THREAD_run_once (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4F8D6ED: OPENSSL_init_crypto (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
==69986== by 0x4F08DC3: OPENSSL_init_ssl (in /usr/lib64/mysql/libmysqlclient.so.20.3.25)
return false前应该关闭conn吧
在return false前加上
mysql_close(conn);
mysql_library_end();
你的代码中，如果mysql_real_connect返回NULL，mysql_library_end函数就没有被调用，从而内存泄漏。
mysql、mysql-devel、openssl这些库也更新成最新的了，用的centos系统
1，从dump堆栈看，泄露是因为mysql内部调用openssl接口引起的。如果调用mysql接口的姿势没错，那么这问题用你现在的版本，没法解决。
2，可以写个测试程序，循环高频调用mysql相关接口，观察一段时间，看内存变化大不。如果不大，那么对你的程序内存及性能影响将不会很大；如果比较大，那么为了防止服务某天暴雷，可以用watchdog对服务程序进行监控，内存达到设定阈值时，自动重启服务，总比暴雷好。
以下是一些建议：
1，如果你的项目是新建的项目，优先考虑使用mysq8.0。而对于8.0，考虑到稳定性、性能等方面，不一定优先考虑最新版本。据调查，银行现在使用的都是8.0.18版本。
2，如果你的项目是从mysql5升上来的，建议使用5.7.35。