MYSQL编程：MYSQL服务保护及使用计划条记

DBaaS解决方案可以降低首次投入成本，对于那些小企业来说，他们往往认为内部部署的数据库成本太高，DBaaS的成本和灵活性优势对小企业吸引力更大，他们是云数据库解决方案的重点客户群体。以下是利用MYSQL服务的一些履历，次要从以下几个方面思索的MYSQL服务计划计划。
1MYSQL服务的安装/设置的通用性；
2体系的晋级和数据迁徙便利性；
3备份和体系疾速恢复；
　　MYSQL服务器的计划
为了今后保护，晋级备份的便利和数据的平安性，最好将MYSQL程叙文件和数据分离安装在“分歧的硬件”上。
　　/
　　/usr<==操纵体系}==>硬盘1
　　/home/mysql<==mysql使用程序
　　...
　　/data/app_1/<==使用数据和剧本}==>硬盘2
　　/data/app_2/
　　/data/app_3/
　　mysql服务的安装和服务的启动：
　　MYSQL一样平常利用以后STABLE的版本，只管不利用--with-charset=选项，我感到with-charset只在按字母排序的时分才有效，这些选项会对数据的迁徙带来良多贫苦。
　　configure--prefix=/home/mysql
　　make
　　makeinstall
　　服务的启动和中断
　　1复制缺省的mysql/var/mysql到/data/app_1/目次下
　　2MYSQLD的启动剧本：
　　start_mysql.sh
　　#!/bin/sh
　　rundir=`dirname"$0"`
　　echo"$rundir"
　　/home/mysql/bin/safe_mysqld--user=mysql--pid-file="$rundir"/mysql.pid--datadir="$rundir"/var"$@"
　　-Omax_connections=500-Owait_timeout=600-Okey_buffer=32M--port=3402--socket="$rundir"/mysql.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
　　/data/app_3/start_mysql.sh
注重：必需写全路径
3MYSQLD的中断剧本：stop_mysql.sh
　　#!/bin/sh
　　rundir=`dirname"$0"`
　　echo"$rundir"
　　/home/mysql/bin/mysqladmin-umysql-S"$rundir"/mysql.sockshutdown

利用这个剧本的优点在于：
1多个服务启动：只必要修正剧本中的--port=参数。单个目次下的数据和服务剧本都是能够自力打包的。
2一切服务响应文件都位于/data/app_1/目次下：好比：mysql.pidmysql.sock，当一台服务器上启动多个服务时，多个服务不会相互影响。但都放到缺省的/tmp/下则有大概被其他使用误删。
3当硬盘1出成绩今后，间接将硬盘2放到一台装好MYSQL的服务器上就能够立即恢复服务（假如放到my.cnf里则还必要备份响应的设置文件）。
服务启动后/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_2_db_2/
　　　...
　　/data/app_2/
　　　...
检察一切的使用历程ID：
　　cat/data/*/mysql.pid
检察一切数据库的毛病日记：
　　cat/data/*/var/*.err
团体倡议：MYSQL的次要瓶颈在PORT的毗连数上，因而，将表布局优化好今后，响应单个MYSQL服务的CPU占用仍旧在10％以上，就要思索将服务拆分到多个PORT上运转了。
　　服务的备份
只管利用MYSQLDUMP而不是间接备份数据文件，以下是一个按weekday将数据轮循备份的剧本：备份的距离和周期能够依据备份的需求断定
　　/home/mysql/bin/mysqldump-S/data/app_1/mysql.sock-umysqldb_name|gzip-f>/path/to/backup/db_name.`data+%w`.dump.gz
　　
因而写在CRONTAB中通常为：
　　*6***/home/mysql/bin/mysqldump-S/data/app_1/mysql.sock-umysqldb_name|gzip-f>/path/to/backup/db_name.`data+\%w`.dump.gz
注重：
　　1在crontab中%必要本义成\%
　　2依据日记统计，使用负载最低的时分通常为在早上6点
　　先备份在当地然后传到远程的备份服务器上，大概间接创建一个数据库备份帐号，间接在远程的服务器上备份，远程备份只必要将以上剧本中的-S/path/to/msyql.sock改成-hIP.ADDRESS便可。
数据的恢复和体系的晋级
　　一样平常保护和数据迁徙：在数据盘没有被损坏的情形下硬盘通常为体系中寿命最低的硬件。而体系（包含操纵体系和MYSQL使用）的晋级和硬件晋级，城市碰到数据迁徙的成绩。只需数据稳定，先装好服务器，然后间接将数据盘（硬盘2）安装上，只必要将启动剧本从头到场到rc.local文件中，体系就算是很好的恢复了。
劫难恢复：数据自己被损坏的情形下断定损坏的工夫点，然后从备份数据中恢复。
使用的计划要点
1.非用数据库不成吗？
　　数据库切实其实能够简化良多使用的布局计划，但自己也是一个体系资本损耗对照年夜的使用。以是良多使用假如没有很高的及时统计需求的话，完整能够先纪录到文件日记中，按期的导进到数据库中做后续统计剖析。假如仍是必要纪录2维表布局，布局充足复杂的话可使用DBM布局。即便必要利用数据库的，使用假如没有太庞大的数据完全性需求的化，完整能够不利用那些撑持外键的贸易数据库。
2.数据库服务的次要瓶颈：单个服务的毗连数关于一个使用来讲，假如数据库表布局的计划可以依照数据库道理的范式来计划的话，而且已利用了最新版本的MYSQL，而且依照对照优化的体例运转了，那末最初的次要瓶颈一样平常在于单个服务的毗连数，即便一个数据库能够撑持并发500个毗连，最好也不要把使用用到这个境地，由于并发毗连数过量数据库服务自己用于调剂的线程的开支也会十分年夜了。以是假如使用同意的话：让一台呆板多跑几个MYSQL服务分管。将服务平衡的计划到多个MYSQL服务端口上：好比app_1==>3301app_2==>3302...app_9==>3309。一个1G内存的呆板跑上10个MYSQL是很一般的。让10个MYSQLD承当1000个并发毗连效力要比让2个MYSQLD承当1000个效力高的多。固然，如许也会带来一些使用编程上的庞大度；
3.利用独自的数据库服务器（不要和前台WEB服务抢内存），MYSQL具有更多的内存便可能能无效的举行了局集的缓存；
4.使用只管利用PCONNECT和polling机制，用于节俭MYSQL服务创建毗连的开支；
5.表的横向拆分：让最常被会见的10%的数据放在一个小内外，90%的汗青数据放在一个回档内外，数据两头经由过程按期“搬场”和按期删除有效数据来节俭。如许关于使用来讲老是在10%数据中举行选择，对照有益于数据的缓存，不要期望MYSQL中对单表纪录数在10万级以上另有对照高的效力。
6.表的纵向拆分（过渡范化）：将一切的定长字段（char,int等）放在一个内外，一切的变长字段（varchar,text,blob等）放在别的一个内外，2个表之间经由过程主键联系关系，如许，定长字段表能够失掉很年夜的优化（乃至可使用HEAP表范例，数据完整在内存中存取），这里也申明别的一个准绳，关于我们来讲，只管利用定长字段能够经由过程空间的丧失调换会见效力的进步。MYSQL之以是撑持多种表范例，实践上是针对分歧使用供应了分歧的优化体例；
7.细心的反省使用的索引计划，乃至在服务启动中到场--log-slow-queries[=file]用于跟踪剖析使用瓶颈。

正如前文所提到的，MySQL易学、易部署、易管理和易维护。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

groupby子句可以将查询结果分组，并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。

学习SQL语言的话如果要学会去做网站就不是很难!但是要做数据库管理的话就有难度了!

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

SP4是一个累积性的ServicePack，包含自以前的ServicePack发布以来所有的修补程序（包括MS03-031安全公告）。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。