备份数据库报错
原因：由于监控服务器最近cpu负载比较高。(cpu4核心，负载2.7左右)感觉很奇怪，因为别的服务器mysql占用的资源并不多，因此我首先优化了数据库的配置文件。cpu稍微下降了一点，但是没有特别明显的变化。
于是，从mysql的存储引擎和日志考虑，结果发现默认用的引擎是myisam。好吧。换成innodb，(由于事先我没备份，就在配置文件修改了引擎，因为日志除了二进制其他并没有开启。所以没动它。重启数据库。
ok
早就听说这两个引擎，区别，看来性能差别真大啊！
好吧。备份数据库吧！
使用备份全部数据库时候
mysqldump: Got error: 23: Out of resourceswhen opening file‘./mysql/jchigr32.MYD‘ (Errcode: 24) when using LOCK TABLES
原因
出现Outof resources when opening file ‘./xxx.MYD‘ (Errcode: 23)错误是
因为打开的文件数超过了f的--open-files-limit。open-files-limit选项
无法在mysql命令行直接修改，必须在f中设定，最大值是65536。
首先用ulimit-n命令查看下打开文件数限制：
默认是1024
解决
vim /etc/f
open_files_limit=65536(最大)
重启mysql ok
检查
mysqlcheck -uroot -pxxx mysql
Error : Youcan‘t use locks with log tables.
Error : Table‘mysql.tempmix‘ doesn‘t exist
status :Operation failed
mysql.tempmix1
Error : Table‘mysql.tempmix1‘ doesn‘t exist
status :Operation failed
mysql.tempmix4
Error : Table‘mysql.tempmix4‘ doesn‘t exist
status :Operation failed
好吧！请教谷歌大神
使用LOCK TABLES时，mysqldump的表不存在
症状
MySQL数据库转储失败，错误：
mysqldump: Goterror: 1146: Table ‘‘ doesn‘t exist when using LOCK TABLES
原因也许有人删除并重新创建InnoDB数据文件却忘了从数据库目录中删除InnoDB表的相应的.FRM文件，或者有人移动.FRM文件到另一个数据库。 请与show tables
不正确的权限和所有权上表文件MySQL数据目录
表已损坏
表中创建大写
解析度请与show tables ，如果表中未列出的举动.frm从数据库目录文件出来
权限和所有权在MySQL数据目录表的文件是不正确的，理想的所有者应该是MySQL用户和权限设置为660。
修复表
设置lower_case_table_names
如果以上所有点都ok然后尝试使用--skip-lock-tables参数用mysqldump 。
根据上面的思路，很快解决！
如果出现这种错误，建议单独备份数据库。
如果觉得《mysql修改存储引擎报错_修改mysql存储引擎备份数据库报错及解决方案》对你有帮助，请点赞、收藏，并留下你的观点哦！
