Mysql优化中遇到的问题和感受

Mysql优化中遇到的问题和感受

根据客户需求那边的需求现有2台数据库服务器，一台做主机一台做从机：

由于客户现场的数据库服务器配置很高(CPU12核心，内存32GB，16TB的硬盘)，所以需要对数据库进行优化，在网上找了一大堆的mysql优化文章之后，就根据实际情况来更改my.cnf文件(linux服务器，windows为my.ini)，其中有一个配置参数的thread_concurrency，借用一下网上的解释：

thread_concurrency的值的正确与否, 对mysql的性能影响很大,
在多个cpu(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核),
出现同一时刻只能一个cpu(或核)在工作的情况。 thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU,
那thread_concurrency 的应该为4; 2个双核的cpu, thread_concurrency的值应为8.

着手开始改吧，我想我也不改2倍了直接改一倍就改为12得了，另外还修改了一下innodb_buffer_pool_size=10240M 这个参数可为可用内存的80%,我还是保守点吧设置个10G，当时重启了一下mysql无任何问题，正常可以使用，查看网站的拿到数据的速度和以前也有了很大的提高(10倍左右)，这个事就告知客户就这样悄悄结束了….

转机

就在昨天客户通知我，说数据库占用CPU过高，导致程序运行缓慢，我远程top查看了一下的确很高，后来客户那边的运维人员打算重启一下mysql，问题出现了mysql重启失败，然后就开始喊我。晚上到家后我开始找原因吧，找啊找，各种网上的办法都试过了，包括没有读写权限的问题，日志文件过多的问题，但是最后我还是通过查看错误日志看到报错，说什么setting value 12o threadXXXXX，我想应该是设置什么线程值导致，我首先想到了配置文件中有这个设置线程的地方，而且还是12，我就尝试更改了一下，然后重启一下mysql果然成功。

感受

mysql数据库的一些自救措施还是比较多的，一般不会重新安装，出错后首先先百度谷歌一下，经过所有的尝试之后再下结论。另外日志文件一定要有最起码要有错误日志文件，方便查找问题。