2022年MySQL服务维护笔记Mysql教程.docx

2022年MySQL服务维护笔记Mysql教程
以下就是针对MySQL作为特地的数据库服务器的优化建议：
MySQL服务器的规划
为了以后维护，升级备份的便利和数据的平安性，最好将MySQL程序文件和数据分别安装在“不同的硬件数据区 mysql/ 用户库 app_1_db_1/ 应用库 app_1_db_2/.../data/app_2/...
查看全部的应用进程ID：
cat /data/*/
查看全部数据库的错误日志：
cat /data/*/var/*.err
个人建议：MySQL的主要瓶颈在PORT的连接数上，因此，将表结构优化好以后，相应单个MySQL服务的CPU占用仍旧在10％以上，就要考虑将服务拆分到多个PORT上运行了。
服务的备份
尽量运用MySQL DUMP而不是干脆备份数据文件，以下是一个按weekday将数据轮循备份的脚本：备份的间隔和周期可以依据备份的需求确定
/home/mysql/bin/mysqldump -S/data/app_1/ -umysql db_name | gzip -f>/path/to/backup/db_name.`data +%w`.
因此写在CRONTAB中一般是：
15 4 * * * /home/mysql/bin/mysqldump -S/data/app_1/ -umysql db_name | gzip -f>/path/to/backup/db_name.`data +\%w`.
留意：
1 在crontab中'%'须要转义成'\%'
2 依据日志统计，应用负载最低的时候一般是在早上4-6点
先备份在本地然后传到远程的备份服务器上，或者干脆建立一个数据库备份帐号，干脆在远程的服务器上备份，远程备份只须要将以上脚本中的-S /path/to/-h 。
数据的复原和系统的升级
日常维护和数据迁移：在数据盘没有被破坏的状况下，硬盘一般是系统中寿命最低的硬件。而系统（包括操作系统和MySQL应用）的升级和硬件升级，都会遇到数据迁移的问题。
只要数据不变，先装好服务器，然后干脆将数据盘（硬盘2）安装上，，系统就算是很好的复原了。
灾难复原：数据库数据本身被破坏的状况下，确定破坏的时间点，然后从备份数据中复原。
[1][2]下一页

应用的设计要点
假如MySQL应用占用的CPU超过10%就应当考虑优化了。
（比如许多基于数据库的计数器完全可以用WEB日志统计代替）最好将其禁用。非用数据库不行吗？虽然数据库的确可以简化许多应用的结构设计，但本身也是一个系统资源消耗比较大的应用。在某些状况下文本，DBM比数据库是更好的选择，比如：许多应用假如没有很高的实时统计需求的话，完全可以先记录到文件日志中，定期的导入到数据库中做后续统计分析。假如还是须要记录简洁的2维键－值对应结构的话可以运用类