《2022年MySQL服务维护笔记Mysql教程.docx》由会员分享，可在线阅读，更多相关《2022年MySQL服务维护笔记Mysql教程.docx（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、2022年MySQL服务维护笔记Mysql教程以下就是针对MySQL作为特地的数据库服务器的优化建议：MySQL服务器的规划为了以后维护，升级备份的便利和数据的平安性，最好将MySQL程序文件和数据分别安装在“不同的硬件”上。 / / | /usr <= 操作系统| /home/mysql <= mysql主书目，为了便利升级，这只硬盘1=>| 是一个最新版本书目的链接| /home/mysql-3.23.54/ <= 最新版本的mysql /home/mysql链接到这里 /home/mysql-old/ <= 以前运行的旧版本的mysql / /data/ap
2、p_1/ <= 应用数据和启动脚本等 硬盘2=>| /data/app_2/ /data/app_3/ MySQL服务的安装和服务的启动MySQL一般运用当前STABLE的版本：尽量不运用-with-charset=选项，我感觉with-charset只在按字母排序的时候才有用，这些选项会对数据的迁移带来许多麻烦。尽量不运用innodb，innodb主要用于须要外键，事务等企业级支持，代价是速度比MYISAM有数量级的下降。./configure -prefix=/home/mysql -without-innodbmakemake install服务的启动和停止1 复制缺省的my
3、sql/var/mysql到 /data/app_1/书目下。2 MySQLD的启动脚本：start_mysql.sh#!/bin/shrundir=dirname $0echo $rundir/home/mysql/bin/safe_mysqld -user=mysql -pid-file=$rundir/mysql.pid -datadir=$rundir/var $-O max_connections=500 -O wait_timeout=600 -O key_buffer=32M -port=3402 -socket=$rundir/m
4、ysql.sock注释：-pid-file=$rundir/mysql.pid -socket=$rundir/mysql.sock -datadir=$rundir/var目的都是将相应数据和应用临时文件放在一起；-O 后面一般是服务器启动全局变量优化参数，有时候须要依据详细应用调整；-port: 不同的应用运用PORT参数分布到不同的服务上去，一个服务可以供应的连接数一般是MySQL服务的主要瓶颈；修改不同的服务到不同的端口后，在rc.local文件中加入：/data/app_1/start_mysql.sh/data/app_2/start_mysql.sh/da
5、ta/app_3/start_mysql.sh留意：必需写全路径3 MySQLD的停止脚本：stop_mysql.sh#!/bin/shrundir=dirname $0echo $rundir/home/mysql/bin/mysqladmin -u mysql -S$rundir/mysql.sock shutdown运用这个脚本的好处在于：1 多个服务启动：对于不同服务只须要修改脚本中的-port=端口号参数。单个书目下的数据和服务脚本都是可以独立打包的。2 全部服务相应文件都位于/data/app_1/书目下：比如：mysql.pid mysql.sock，当一
6、台服务器上启动多个服务时，多个服务不会相互影响。但都放到缺省的/tmp/下则有可能被其他应用误删。3 当硬盘1出问题以后，干脆将硬盘2放到一台装好MySQL的服务器上就可以立即复原服务（假如放到f里则还须要备份相应的配置文件）。服务启动后/data/app_1/下相应的文件和书目分布如下：/data/app_1/ start_mysql.sh 服务启动脚本 stop_mysql.sh 服务停止脚本 mysql.pid 服务的进程ID mysql.sock 服务的SOCK var/ 数据区 mysql/ 用户库 app_1_db_1/ 应用库 app_1_db_2/./data/app_2/.查
7、看全部的应用进程ID：cat /data/*/mysql.pid查看全部数据库的错误日志：cat /data/*/var/*.err个人建议：MySQL的主要瓶颈在PORT的连接数上，因此，将表结构优化好以后，相应单个MySQL服务的CPU占用仍旧在10以上，就要考虑将服务拆分到多个PORT上运行了。服务的备份尽量运用MySQL DUMP而不是干脆备份数据文件，以下是一个按weekday将数据轮循备份的脚本：备份的间隔和周期可以依据备份的需求确定/home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -umysql db_name | gzip -
8、f>/path/to/backup/db_name.data +%w.dump.gz因此写在CRONTAB中一般是：15 4 * * * /home/mysql/bin/mysqldump -S/data/app_1/mysql.sock -umysql db_name | gzip -f>/path/to/backup/db_name.data +%w.dump.gz留意：1 在crontab中%须要转义成%2 依据日志统计，应用负载最低的时候一般是在早上4-6点先备份在本地然后传到远程的备份服务器上，或者干脆建立一个数据库备份帐号，干脆在远程的服务器上备份，远程备份只须要将以上
9、脚本中的-S /path/to/msyql.sock改成-h IP.ADDRESS即可。数据的复原和系统的升级日常维护和数据迁移：在数据盘没有被破坏的状况下，硬盘一般是系统中寿命最低的硬件。而系统（包括操作系统和MySQL应用）的升级和硬件升级，都会遇到数据迁移的问题。只要数据不变，先装好服务器，然后干脆将数据盘（硬盘2）安装上，只须要将启动脚本重新加入到rc.local文件中，系统就算是很好的复原了。灾难复原：数据库数据本身被破坏的状况下，确定破坏的时间点，然后从备份数据中复原。12下一页 应用的设计要点假如MySQL应用占用的CPU超过10%就应当考虑优化了。1.假如这个服务可以被其他非数
10、据库应用代替（比如许多基于数据库的计数器完全可以用WEB日志统计代替）最好将其禁用。非用数据库不行吗？虽然数据库的确可以简化许多应用的结构设计，但本身也是一个系统资源消耗比较大的应用。在某些状况下文本，DBM比数据库是更好的选择，比如：许多应用假如没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导入到数据库中做后续统计分析。假如还是须要记录简洁的2维键值对应结构的话可以运用类似于DBM的HEAP类型表。因为HEAP表全部在内存中存取，效率特别高，但服务器突然断电时有可能出现数据丢失，所以特别适合存储在线用户信息，日志等临时数据。即使须要运用数据库的，应用假如没有太困难的数据完整性
11、需求的化，完全可以不运用那些支持外键的商业数据库，比如MySQL。只有特别须要完整的商业逻辑和事务完整性的时候才须要Oracle这样的大型数据库。对于高负载应用来说完全可以把日志文件，DBM，MySQL等轻量级方式做前端数据采集格式，然后用Oracle MSSQL DB2 Sybase等做数据库仓库以完成困难的数据库挖掘分析工作。有挚友和我说用标准的MyISAM表代替了InnoDB表以后，数据库性能提高了20倍。2.数据库服务的主要瓶颈：单个服务的连接数。对于一个应用来说，假如数据库表结构的设计能够根据数据库原理的范式来设计的话，并且已经运用了最新版本的MySQL，并且根据比较优化的方式运行了
12、，那么最终的主要瓶颈一般在于单个服务的连接数，即使一个数据库可以支持并发500个连接，最好也不要把应用用到这个地步，因为并发连接数过多数据库服务本身用于调度的线程的开销也会特别大了。所以假如应用允许的话：让一台机器多跑几个MySQL服务分担。将服务均衡的规划到多个MySQL服务端口上：比如app_1 => 3301 app_2 => 3302.app_9 => 3309。一个1G内存的机器跑上10个MySQL是很正常的。让10个MySQLD担当1000个并发连接效率要比让2个MySQLD担当1000个效率高的多。当然，这样也会带来一些应用编程上的困难度；3.运用单独的数据库服
13、务器（不要让数据库和前台WEB服务抢内存），MySQL拥有更多的内存就可能能有效的进行结果集的缓存；在前面的启动脚本中有一个-O key_buffer=32M参数就是用于将缺省的8M索引缓存增加到32M（当然对于）4.应用完量运用PCONNECT和polling机制，用于节约MySQL服务建立连接的开销，但也会造成MySQL并发链接数过多（每个HTTPD都会对应一个MySQL线程）；5.表的横向拆分：让最常被访问的10%的数据放在一个小表里，90%的历史数据放在一个归档表里（所谓：快慢表），数据中间通过定期“搬家”和定期删除无效数据来节约，终归大部分应用（比如论坛）访问2个月前数据的几率会特别
14、少，而且价值也不是很高。这样对于应用来说总是在一个比较小的结果级中进行数据选择，比较有利于数据的缓存，不要希望MySQL中对单表记录条数在10万级以上还有比较高的效率。而且有时候数据没有必要做那么精确，比如一个快表中查到了某个人发表的文章有60条结果，快表和慢表的比例是1:20，那么就可以简洁的估计这个人一共发表了1200篇。Google的搜寻结果数也是一样：对于许多上十万的结果数，后面许多的数字都是通过肯定的算法估计出来的。6.数据库字段设计：表的纵向拆分（过渡范化）：将全部的定长字段（char, int等）放在一个表里，全部的变长字段（varchar,text,blob等）放在另外一个表里，2个表之间通过主键关联，这样，定长字段表可以得到很大的优化（这样可以运用HEAP表类型，数据完全在