一、故障类型1
◆故障描述：ibdata1、MYI、MYD损坏
◆典型特征：
(1)数据库无法进行查询等操作
(2)使用mysqlcheck和myisamchk无法修复数据库
(3)损坏程度星级评价：★★★
二、解决方案
◆检测流程：
(1)对损坏的数据库进行备份，防止进一步破坏；
(2)手工对MYD和MYI文件进行内部结构检测；
(3)使用自主开发的程序对ibdata1文件进行检测；
◆实施流程：
(1)将损坏的数据库文件进行手工备份拷贝，以防止二次破坏；
(2)通过自主开发的程序对数据库进行完整检测；
(3)修复损坏的索引或数据文件；
(4)使用自主开发的程序对数据进行提取；
(5)生成数据库。
◆验收流程：
(1)挂载数据库，启动服务；
(2)对数据库做mysqlcheck检测；
(3)对重要表进行数据查询，检验数据的更新日期。
三、 数据恢复的可能
数据库恢复的成功率视其损坏的程序而定。
四、 数据恢复所需时间
也因数据库大小而定，一般时间在1-2个工作日。
五、 服务费用
视数据表的个数及大小不同，价格也不同，恢复费用：3000元起/次
【小贴士】
◆发现数据库损坏后，请及时对数据库备份，不要在没有备份的情况下对数据进行任何修复操作。
◆故障出现的可能原因：
1． 数据库正在操作过程中，机器突然断电
2． 人为误操作或其它原因
◆隐患故障及损坏程度星级评价
隐患1．数据库损坏后未进行过任何修复操作
损坏程度星级评价：★★★
隐患2．数据库损坏后，在未备份的情况下对数据库进行修复操作
损坏程度星级评价：★★★★
◆文件保护措施
做好数据库备份工作
一、故障类型2
◆故障类型：数据库表记录删除
◆典型特征：
（1）数据表中无任何数据或只有部分数据
（2）客户端无法查询到完整的信息
◆损坏程度星级评价：★★★★
二、解决方案
◆检测流程：
（1）使用磁盘编辑器对数据文件MYD进行分析；
（2）判断表记录丢失的可能原因。
◆实施流程：
（1）将损坏的数据库文件进行备份；
（2）对数据库文件进行分析，判断丢失的可能原因；
（3）针对不同的丢失原因，使用自主开发的软件进行数据恢复；
（4）将数据插入原数据库，对数据库做完整性检测。
◆验收流程：
（1）对数据库做mysqlcheck检测；
（2）查询数据库最新记录；
（3）对用户指定的关键数据表进行针对性校验。
三、数据恢复的可能性
数据库的表记录删除后，如未做其它任何操作，因MYD内容结构的原因，数据恢复成功率不可达到100％。
四、数据恢复所需
时间视数据库大小而定，约为1-2天不等
五、服务费用
数据库表记录丢失：3000元起/次
【小贴士】
◆发现数据库表记录删除后，请及时对数据库备份，不要再进行数据插入等操作。
◆故障出现的可能原因：
1.对数据库进行升级，SQL语句条件不严格
2.人为操作错误
◆隐患故障及损坏程度星级评价
隐患1：数据库表记录丢失后未做任何操作
损坏程度星级评价：★★★★
隐患2：数据库表丢失后插入新的记录
损坏程度星级评价：★★★★★
◆数据库操作提示：
1.在对数据库进行操作时，尽量先对数据库进行备份；
2.对数据表进行操作时请慎重。
在平时被问及最多的问题就是关于MySQL数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级MySQL DBA以及其他对MySQL性能优化感兴趣的朋友们有所帮助。
数据库属于IO密集型的应用程序，其主职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是IO，尽可能将磁盘IO转化为内存IO。本文先从MySQL数据库IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化：
•query_cache_size/query_cache_type (global)
Query cache作用于整个MySQL Instance，主要用来缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cachehttp://www.aibeili.net，或者已经显式申明需要使用Query Cache)，MySQL会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤(如SQL语句的解析，优化器优化以及向存储引擎请求数据等)，极大的提高性能。
当然，Query Cache也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache可能会得不偿失。
Query Cache的使用需要多个参数配合，其中最为关键的是query_cache_size和query_cache_type，前者设置用于缓存ResultSet的内存大小，后者设置在何场景下使用Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size一般256MBhttp://www.aibeili.net是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有显示要求才使用query cache(使用sql_cache)。
•binlog_cache_size (global)
Binlog Cache用于在打开了二进制日志(binlog)记录功能的环境，是MySQL用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。
一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use以及binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件(binlog_cache_disk_use)来缓存了。
本文转载于51cto博客