MySQL优化

MySQL如何优化

• 表的设计合理化(符合3NF)
• 添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]
• SQL语句优化
• 分表技术(水平分割、垂直分割)
• 读写[写: update/delete/add]分离
• 存储过程 [模块化编程，可以提高速度]
• 对mysql配置优化 [配置最大并发数my.ini, 调整缓存大小 ]
• mysql服务器硬件升级
• 定时的去清除不需要的数据,定时进行碎片整理(MyISAM)

数据库设计

数据库三大范式

• 第一范式：1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF)
• 第二范式：2NF是对记录的惟一性约束，表中的记录是唯一的, 就满足2NF, 通常我们设计一个主键来实现，主键不能包含业务逻辑。
• 第三范式：3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。
  但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

分表分库

垂直拆分

垂直拆分就是要把表按模块划分到不同数据库表中（当然原则还是不破坏第三范式），这种拆分在大型网站的演变过程中是很常见的。当一个网站还在很小的时候，只有小量的人来开发和维护，各模块和表都在一起，当网站不断丰富和壮大的时候，也会变成多个子系统来支撑，这时就有按模块和功能把表划分出来的需求。其实，相对于垂直切分更进一步的是服务化改造，说得简单就是要把原来强耦合的系统拆分成多个弱耦合的服务，通过服务间的调用来满足业务需求看，因此表拆出来后要通过服务的形式暴露出去，而不是直接调用不同模块的表，淘宝在架构不断演变过程，最重要的一环就是服务化改造，把用户、交易、店铺、宝贝这些核心的概念抽取成独立的服务，也非常有利于进行局部的优化和治理，保障核心模块的稳定性
垂直拆分用于分布式场景。

水平拆分

上面谈到垂直切分只是把表按模块划分到不同数据库，但没有解决单表大数据量的问题，而水平切分就是要把一个表按照某种规则把数据划分到不同表或数据库里。例如像计费系统，通过按时间来划分表就比较合适，因为系统都是处理某一时间段的数据。而像SaaS应用，通过按用户维度来划分数据比较合适，因为用户与用户之间的隔离的，一般不存在处理多个用户数据的情况，简单的按user_id范围来水平切分
通俗理解：水平拆分行，行数据拆分到不同表中， 垂直拆分列，表数据拆分到不同表中

思路
在大型电商系统中，每天的会员人数不断的增加。达到一定瓶颈后如何优化查询。
可能大家会想到索引，万一用户量达到上亿级别，如何进行优化呢？
使用水平分割拆分数据库表。

分表策略：
使用水平分割拆分表，具体根据业务需求，有的按照注册时间、取摸、账号规则、年份等。取摸方式分表

定位慢查询

使用show status使用show status查看MySQL服务器状态信息

--mysql数据库启动了多少时间
show status like 'uptime';
show  stauts like 'com_select'  show stauts like 'com_insert' ...\
类推 update  delete（显示数据库的查询，更新，添加，删除的次数）
show [session|global] status like .... 如果你不写  [session|global] 默认
是session 会话，指取出当前窗口的执行，如果你想看所有(从mysql 启动到现在，则应该
 global)
//显示到mysql数据库的连接数
show status like  'connections '; 
//显示慢查询次数
show status like 'slow_queries';

如何将慢查询定位到日志中

在默认情况下，我们的mysql不会记录慢查询，需要在启动mysql时候，指定记录慢查询才可以
bin\mysqld.exe --safe-mode --slow-query-log [mysql5.5 可以在my.ini指定]（安全模式启动，数据库将操作写入日志，以备恢复）
bin\mysqld.exe –log-slow-queries=d:/abc.log [低版本mysql5.0可以在my.ini指定]
先关闭mysql,再启动, 如果启用了慢查询日志，默认把这个文件放在
my.ini 文件中记录的位置
#Path to the database root
datadir=" C:/ProgramData/MySQL/MySQL Server 5.5/Data/"

主从复制

影响MySQL-A数据库的操作，在数据库执行后，都会写入本地的日志系统A中。
假设，实时的将变化了的日志系统中的数据库事件操作，在MYSQL-A的3306端口，通过网络发给MYSQL-B。MYSQL-B收到后，写入本地日志系统B，然后一条条的将数据库事件在数据库中完成, 那么，MYSQL-A的变化，MYSQL-B也会变化，这样就是所谓的MYSQL的复制，即MYSQL replication。

在上面的模型中，MYSQL-A就是主服务器，即master，MYSQL-B就是从服务器，即slave。
日志系统A，其实它是MYSQL的日志类型中的二进制日志，也就是专门用来保存修改数据库表的所有动作，即bin log。注意MYSQL会在执行语句之后，释放锁之前，写入二进制日志，确保事务安全】
日志系统B，并不是二进制日志，由于它是从MYSQL-A的二进制日志复制过来的，并不是自己的数据库变化产生的，有点接力的感觉，称为中继日志，即relay log。
可以发现，通过上面的机制，可以保证MYSQL-A和MYSQL-B的数据库数据一致，但是时间上肯定有延迟，即MYSQL-B的数据是滞后的。
【即便不考虑什么网络的因素，MYSQL-A的数据库操作是可以并发的执行的，但是MYSQL-B只能从relay log中读一条，执行下。因此MYSQL-A的写操作很频繁，MYSQL-B很可能跟不上。】

数据如何不被丢失

• 备份
• 读写分离
• 数据库负载均衡
• 高可用

服务器准备

192.168.110.177 主服务器 master
192.168.110.178 从服务器slave

主(master)服务器

vi /etc/my.cnf  新增以下内容
server_id=177  ###服务器id
log-bin=mysql-bin   ###开启日志文件

重启服务器
service mysqld start
service iptables stop

主服务器给从服务器账号授权
GRANT REPLICATION SLAVE ON *.* to 'mysync'@'%' identified by 'q123456';

登录主服务器的mysql，查询master的状态
如果结果为null,则主服务器my.cf没有配置好.

修改从(slave)服务器

server_id=178
log-bin=mysql-bin
binlog_do_db=test

change master to 
master_host='192.168.110.177',
master_user='mysync',
master_password='q123456',
master_log_file='mysql-bin.000002',
master_log_pos=343;

启动同步
start slave

检查从服务器复制功能状态
SHOW SLAVE STATUS

Slave_IO_Running: Yes //此状态必须YES
Slave_SQL_Running: Yes //此状态必须YES

读写分离

在数据库集群架构中，让主库负责处理事务性查询，而从库只负责处理select查询，让两者分工明确达到提高数据库整体读写性能。当然，主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中，也就是写操作。

读写分离的好处

1）分摊服务器压力，提高机器的系统处理效率
读写分离适用于读远比写的场景，如果有一台服务器，当select很多时，update和delete会被这些select访问中的数据堵塞，等待select结束，并发性能并不高，而主从只负责各自的写和读，极大程度的缓解X锁和S锁争用；
假如我们有1主3从，不考虑上述1中提到的从库单方面设置，假设现在1分钟内有10条写入，150条读取。那么，1主3从相当于共计40条写入，而读取总数没变，因此平均下来每台服务器承担了10条写入和50条读取（主库不承担读取操作）。因此，虽然写入没变，但是读取大大分摊了，提高了系统性能。另外，当读取被分摊后，又间接提高了写入的性能。所以，总体性能提高了，说白了就是拿机器和带宽换性能；

2）增加冗余，提高服务可用性，当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务

MyCat

一个开源的分布式数据库系统，但是因为数据库一般都有自己的数据库引擎，而Mycat并没有属于自己的独有数据库引擎，所有严格意义上说并不能算是一个完整的数据库系统，只能说是一个在应用和数据库之间起桥梁作用的中间件。

在Mycat中间件出现之前，MySQL主从复制集群，如果要实现读写分离，一般是在程序段实现，这样就带来了一个问题，即数据段和程序的耦合度太高，如果数据库的地址发生了改变，那么我的程序也要进行相应的修改，如果数据库不小心挂掉了，则同时也意味着程序的不可用，而对于很多应用来说，并不能接受；

引入Mycat中间件能很好地对程序和数据库进行解耦，这样，程序只需关注数据库中间件的地址，而无需知晓底层数据库是如何提供服务的，大量的通用数据聚合、事务、数据源切换等工作都由中间件来处理；

Mycat中间件的原理是对数据进行分片处理，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成完成的数据库存储，有点类似磁盘阵列中的RAID0.

Mycat安装

CREATE DATABASE IF NOT EXISTS `weibo_simple`;
-- ------------------------------------
-- Table structure for `t_users` 用户表
-- ------------------------------------
DROP TABLE IF EXISTS `t_users`;
CREATE TABLE `t_users` (
  `user_id` varchar(64) NOT NULL COMMENT '注册用户ID',
  `user_email` varchar(64) NOT NULL COMMENT '注册用户邮箱',
  `user_password` varchar(64) NOT NULL COMMENT '注册用户密码',
  `user_nikename` varchar(64) NOT NULL COMMENT '注册用户昵称',
  `user_creatime` datetime NOT NULL COMMENT '注册时间',
  `user_status` tinyint(1) NOT NULL COMMENT '验证状态  1：已验证  0：未验证',
  `user_deleteflag` tinyint(1) NOT NULL COMMENT '删除标记  1：已删除 0：未删除',
  PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- -------------------------------------
-- Table structure for `t_message`微博表
-- -------------------------------------
DROP TABLE IF EXISTS `t_message`;
CREATE TABLE `t_message` (
  `messages_id` varchar(64) NOT NULL COMMENT '微博ID',
  `user_id` varchar(64) NOT NULL COMMENT '发表用户',
  `messages_info` varchar(255) DEFAULT NULL COMMENT '微博内容',
  `messages_time` datetime DEFAULT NULL COMMENT '发布时间',
  `messages_commentnum` int(12) DEFAULT NULL COMMENT '评论次数',
  `message_deleteflag` tinyint(1) NOT NULL COMMENT '删除标记 1：已删除 0：未删除',
  `message_viewnum` int(12) DEFAULT NULL COMMENT '被浏览量',
  PRIMARY KEY (`messages_id`),
  KEY `user_id` (`user_id`),
  CONSTRAINT `t_message_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `t_users` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

配置server.xml

<!-- 添加user -->
   <user name="mycat">
    <property name="password">mycat</property>
    <property name="schemas">mycat</property>
    </user>
	
	<!-- 添加user -->
   <user name="mycat_red">
    <property name="password">mycat_red</property>
    <property name="schemas">mycat</property>
	<property name="readOnly">true</property>
    </user>

• 配置schema.xml

<?xml version="1.0"?>
<!DOCTYPE mycat:schema SYSTEM "schema.dtd">
<mycat:schema xmlns:mycat="http://org.opencloudb/">
<!-- 与server.xml中user的schemas名一致 -->
<schema name="mycat" checkSQLschema="true" sqlMaxLimit="100">

<table name="t_users" primaryKey="user_id" dataNode="dn1" rule="rule1"/>
<table name="t_message" type="global" primaryKey="messages_id" dataNode="dn1" />
</schema>

<dataNode name="dn1" dataHost="jdbchost" database="weibo_simple"/>

<dataHost name="jdbchost" maxCon="1000" minCon="10" balance="1"
      writeType="0" dbType="mysql" dbDriver="native" switchType="1"
      slaveThreshold="100">
<heartbeat>select user()</heartbeat>  
<writeHost host="hostMaster" url="172.27.185.1:3306" user="root" password="root">
</writeHost>
<writeHost host="hostSlave" url="172.27.185.2:3306" user="root" password="root"/>
</dataHost>
</mycat:schema>

• 配置rule.xml文件

<mycat:rule xmlns:mycat="http://org.opencloudb/">
	 <tableRule name="rule1">
        <rule>
            <columns>user_id</columns>
            <algorithm>func1</algorithm>
        </rule>
    </tableRule>
    <function name="func1" class="org.opencloudb.route.function.AutoPartitionByLong">
  	<property name="mapFile">autopartition-long.txt</property>
    </function>
</mycat:rule>