MySQL服务维护笔记 续

核心提示：服务的备份 尽量使用MySQL(和PHP搭配之最佳组合) DUMP而不是直接备份数据文件，以下是一个按weekday将数据轮循备份的脚本：备份的间隔和周期可以根据备份的需求确定/home/MySQL(和PHP搭配之最佳组合)/bin/MySQL(和PHP搭配之最佳组合)dump -S/data/app_1/MySQL(

服务的备份

尽量使用MySQL(和PHP搭配之最佳组合) DUMP而不是直接备份数据文件，以下是一个按weekday将数据轮循备份的脚本：备份的间隔和周期可以根据备份的需求确定
/home/MySQL(和PHP搭配之最佳组合)/bin/MySQL(和PHP搭配之最佳组合)dump -S/data/app_1/MySQL(和PHP搭配之最佳组合).sock -uMySQL(和PHP搭配之最佳组合) db_name | gzip -f>/path/to/backup/db_name.`data +%w`.dump.gz

因此写在CRONTAB中一般是：
15 4 * * * /home/MySQL(和PHP搭配之最佳组合)/bin/MySQL(和PHP搭配之最佳组合)dump -S/data/app_1/MySQL(和PHP搭配之最佳组合).sock -uMySQL(和PHP搭配之最佳组合) db_name | gzip -f>/path/to/backup/db_name.`data +\%w`.dump.gz

注意：

1. 在crontab中'%'需要转义成'\%'
　　2. 根据日志统计，应用负载最低的时候一般是在早上4-6点

先备份在本地然后传到远程的备份服务器上，或者直接建立一个数据库备份帐号，直接在远程的服务器上备份，远程备份只需要将以上脚本中的-S /path/to/msyql.sock改成-h IP.ADDRESS即可。

数据的恢复和系统的升级

日常维护和数据迁移：在数据盘没有被破坏的情况下硬盘一般是系统中寿命最低的硬件。而系统（包括操作系统和MySQL(和PHP搭配之最佳组合)应用）的升级和硬件升级，都会遇到数据迁移的问题。

只要数据不变，先装好服务器，然后直接将数据盘（硬盘2）安装上，只需要将启动脚本重新加入到rc.local文件中，系统就算是很好的恢复了。

灾难恢复：数据库数据本身被破坏的情况下确定破坏的时间点，然后从备份数据中恢复。

应用的设计要点

如果MySQL(和PHP搭配之最佳组合)应用占用的CPU超过10%就应该考虑优化了。

如果这个服务可以被其他非数据库应用代替（比如很多基于数据库的计数器完全可以用WEB日志统计代替）最好将其禁用：

非用数据库不可吗？虽然数据库的确可以简化很多应用的结构设计，但本身也是一个系统资源消耗比较大的应用。在某些情况下文本，DBM比数据库是更好的选择，比如：很多应用如果没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导入到数据库中做后续统计分析。如果还是需要记录简单的2维键－值对应结构的话可以使用类似于DBM的HEAP类型表。因为HEAP表全部在内存中存取，效率非常高，但服务器突然断电时有可能出现数据丢失，所以非常适合存储在线用户信息，日志等临时数据。即使需要使用数据库的，应用如果没有太复杂的数据完整性需求的化，完全可以不使用那些支持外键的商业数据库，比如MySQL(和PHP搭配之最佳组合)。只有非常需要完整的商业逻辑和事务完整性的时候才需要Oracle(大型网站数据库平台)这样的大型数据库。对于高负载应用来说完全可以把日志文件，DBM，MySQL(和PHP搭配之最佳组合)等轻量级方式做前端数据采集格式，然后用Oracle(大型网站数据库平台) mssql(WINDOWS平台上强大的数据库平台) DB2 Sybase等做数据库仓库以完成复杂的数据库挖掘分析工作。

有朋友和我说用标准的MyISAM表代替了InnoDB表以后，数据库性能提高了20倍。

数据库服务的主要瓶颈：单个服务的连接数对于一个应用来说，如果数据库表结构的设计能够按照数据库原理的范式来设计的话，并且已经使用了最新版本的MySQL(和PHP搭配之最佳组合)，并且按照比较优化的方式运行了，那么最后的主要瓶颈一般在于单个服务的连接数，即使一个数据库可以支持并发500个连接，最好也不要把应用用到这个地步，因为并发连接数过多数据库服务本身用于调度的线程的开销也会非常大了。所以如果应用允许的话：让一台机器多跑几个MySQL(和PHP搭配之最佳组合)服务分担。将服务均衡的规划到多个MySQL(和PHP搭配之最佳组合)服务端口上：比如app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309。一个1G内存的机器跑上10个MySQL(和PHP搭配之最佳组合)是很正常的。让10个MySQL(和PHP搭配之最佳组合)D承担1000个并发连接效率要比让2个MySQL(和PHP搭配之最佳组合)D承担1000个效率高的多。当然，这样也会带来一些应用编程上的复杂度；

使用单独的数据库服务器（不要让数据库和前台WEB服务抢内存），MySQL(和PHP搭配之最佳组合)拥有更多的内存就可能能有效的进行结果集的缓存；在前面的启动脚本中有一个-O key_buffer=32M参数就是用于将缺省的8M索引缓存增加到32M（当然对于）

应用尽量使用PCONNECT和polling机制，用于节省MySQL(和PHP搭配之最佳组合)服务建立连接的开销，但也会造成MySQL(和PHP搭配之最佳组合)并发链接数过多（每个HTTPD都会对应一个MySQL(和PHP搭配之最佳组合)线程）；

表的横向拆分：让最常被访问的10%的数据放在一个小表里，90%的历史数据放在一个归档表里（所谓：快慢表），数据中间通过定期“搬家”和定期删除无效数据来节省，毕竟大部分应用（比如论坛）访问2个月前数据的几率会非常少，而且价值也不是很高。这样对于应用来说总是在一个比较小的结果级中进行数据选择，比较有利于数据的缓存，不要指望MySQL(和PHP搭配之最佳组合)中对单表记录条数在10万级以上还有比较高的效率。而且有时候数据没有必要做那么精确，比如一个快表中查到了某个人发表的文章有60条结果，快表和慢表的比例是1:20，那么就可以简单的估计这个人一共发表了1200篇。Google的搜索结果数也是一样：对于很多上十万的结果数，后面很多的数字都是通过一定的算法估计出来的。

数据库字段设计：表的纵向拆分（过渡范化）：将所有的定长字段（char, int等）放在一个表里，所有的变长字段（varchar,text,blob等）放在另外一个表里，2个表之间通过主键关联，这样，定长字段表可以得到很大的优化（这样可以使用HEAP表类型，数据完全在内存中存取），这里也说明另外一个原则，对于我们来说，尽量使用定长字段可以通过空间的损失换取访问效率的提高。在MySQL(和PHP搭配之最佳组合)4中也出现了支持外键和事务的InnoDB类型表，标准的MyISAM格式表和基于HASH结构的HEAP内存表，MySQL(和PHP搭配之最佳组合)之所以支持多种表类型，实际上是针对不同应用提供了不同的优化方式；